Gitflow工作流简单介绍（以发布为中心的开发模式）

前言

这是Gitflow的官网：https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow，这篇文章主要介绍Gitflow理念。
以下有些内容来源于《Github入门与实践》。
Gitflow是以发布为中心的分支管理模型，它提供了一种更灵活的方式来管理代码库中的更改。而Github Flow则是以部署为中心的开发模式，通过简单的规则，持续高速且安全地进行部署。详情请看另一片文章Github Flow工作流简单介绍（以部署为中心的开发模式）

基本概念

对于GitFlow，流程是，首先项目的开始Master/Main，分出来Develop，在它基础上进行开发；对于一些功能，单独分出来Feature分支，这些分支实现了，提出merge request，经过管理员同意后，在合并到Develop分支上，原来的Feature可以删除；当Develop开发的差不多了，就branch出Release分支，也就是预发布分支；经过测试没什么问题后，就提交到Master，并创建个标签，也就是第一代正式上线产品（master是稳定版本，release是对外发行的版本；release确定了功能也就基本不变了，只会修修bug）；如果有了问题，在branch出Hotfix，紧急修复后，在合并到Master，也可以再创个标签。

git-flow辅助工具

安装之后，可以使用一些它提供的辅助命令。比如下面那一条，结束feature/1.0.0分支，代码将自动合并到dev分支，此后会自动切换到dev分支。但总之使用起来还是挺麻烦的，尤其是在很多人合作的前提下，书中也进行了详细介绍，这里就不进行描述了，如果真的用到了在进行总结。

git flow feature finish 1.0.0

缺点

这个开发流程的问题在于需要记忆的分支状态很多，在实施之前必须对整个开发流程进行系统地学习。虽然可以提到上文提到的git-flow工具辅助，但很多情况下，流程整体对于我们的实际开发现场来说仍然过于复杂。
在这个过程中，程序员必须理解自己正在进行的修改会对哪些分支产生影响。一个分支的工作结束后，有时需要与多个目标进行分支合并。这些是该流程中最为复杂的部分，同时由于其复杂程度高，容易出现操作失误等人为操作，需要团队谨慎处理。