文章目录
Git分支模型之git flow工作流
git flow工作流是一套工作方式，工作流程。完全可以不安装git-flow工具，用git去实现git flow工作流。
什么是Git Flow 工作流
2010年5月，在一篇名为“A successful Git branching model”的博文中，原Git Prime的首席技术官Vincent Driessen介绍了一种构建在Git（一个开源的分布式版本控制系统）之上的软件开发模型。通过利用Git创建和管理分支的能力，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上，实现了软件开发过程不同阶段的相互隔离。这种软件开发的活动模型被Vincent称为“Git Flow”（Git工作流程）。
Git Flow 被认为是现代连续软件开发和DevOps（开发、技术运营和质量保障三者的交集）实践的最佳实践。
Git Flow 工作流是一个非常成熟的方案，也是非开源项目中最常用到的工作流。 它定义了一个围绕项目发布的严格分支模型，通过为代码开发、发布和维护分配独立的分支来让项目的迭代流程更加顺畅，比较适合大型的项目或者迭代速度快的项目。
它最主要的特点有两个：
- 项目存在两个长期分支。
- 主分支master
- 开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版；后者用于日常开发，存放最新的开发版。
master分支应该受到保护，不是每个人都可以修改这个分支，以及拥有审批 Pull Request 的权力。
Github 和 Gitlab 都提供"保护分支"（Protected branch）这个功能。
相对于使用仅有的一个master分支，Gitflow工作流使用两个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。
master一直是最新的、稳定的、现网正在使用的代码。
- 项目存在三种短期分支：
- 功能分支（feature branch）
功能分支一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支。
模块完成之后，会合并到 develop 分支，然后删除自己。
注意：feature分支不应该从main分支拷贝，而是从最新的开发分支拷贝创建。当一个功能完成后，它会被合并回develop。feature分支不应该直接与 main 交互。
- 补丁分支（hotfix branch）
Hotfix 分支是用来做线上的紧急 bug 修复的分支,建议命名为 hotfix-xxx。当线上某个版本出现了问题，将检出对应版本的代码，创建 Hotfix 分支，问题修复后，合并回 master 和 develop ，然后删除自己。这里注意，合并到 master 的时候，也要打上修复后的版本标签。
当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的tag版本（比如1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如1.2.1）。
热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。
- 预发分支（release branch）
该分支专为测试—发布新的版本而开辟，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。
Release 分支用来做版本发布的预发布分支，建议命名为 release-xxx（请注意，release 分支是使用版本号命名的，是一个明智的选择）。例如在软件 1.0.0 版本的功能全部开发完成，提交测试之后，从 develop 检出release-1.0.0 ,测试中出现的小问题，在 release 分支进行修改提交，测试完毕准备发布的时候，代码会合并到 master 和 develop，master 分支合并后会打上对应版本标签 v1.0.0，合并后删除自己。这样做的好处是，在测试的时候，不影响下一个版本功能并行开发。
预发分支只能拉取自开发分支，合并回开发分支和主要分支。
各个分支作用总结：
- master：主分支，非常稳定的，不用来开发和发布，只用来跟踪已经发布的代码；
- develop：主开发分支，包含确定即将发布的代码；开发都在这个分支；
到发布时，再合并到release上； - feature：新功能分支，一般一个新功能对应一个分支，对于功能的拆分需要比较合理，以 避免一些后面不必要的代码冲突；
- release：发布分支，发布时候用的分支，测试时候发现的 bug直接 在这个分支进行修复；
- hotfix：紧急修 bug 的时候用；
git flow工作中常见问题
采用git flow模式，提测的时候提release分支测试的，如果我有一个release1.0.0的分支在测试中，这个时候又有新的开发任务了，从develop分支切出来，此时的develop分支代码只经过开发测试，还非常不稳定，对于新的feature分支影响还是比较大的，怎么解决。严格安照串行的方式是没有问题的，release1.0.0验证完成，master develop merge完成发布，然后在开始进入下个功能的开发。但是现实场景很容易出现，上一个版本还是测试阶段，就有别的开发任务了。
解决方案：等release1.0.0分支的修复合并到develop分支后，后来新建的功能分支再rebase下develop分支就可以了。
Git Flow的优缺点以及选型考虑
GitFlow的好处
Git Flow模型通过不同的分支从源代码管理的角度对软件开发活动进行了约束，为我们的软件开发提供了一个可供参考的管理模型。Git Flow模型让代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。
- 并行开发：
各个开发人员在自己的分支开发，互不影响。
每个新功能都会建立一个新的 feature分支，从而和已经完成的功能隔离开来，而且只有在新功能完成开发的情况下，其对应的 feature分支才会合并到主开发分支（develop分支）。
- 协作开发：
每个 feature分支多人协同开发。 - 紧急修复：
hotfix（bug） 分支，这种类型的分支是从master分支上创建出来并做一个紧急的修复，而且这个紧急修复只影响这个已经发布的 版本，而不会影响到你正在开发的新 feature。 - 主分支始终处于可发布状态
如果新发布版本出现问题，可以方便的通过tag回滚。
GitFlow的缺点
- 默认工作分支是 develop，但是大部分版本管理工具默认分支都是 master，开始的时候总是需要切换很麻烦。
- Hotfix 和 Release 分支在需要版本快速迭代的项目中，几乎用不到，因为刚开发完就直接合并到 master 发版，出现问题 develop 就直接修复发布下个版本了。
总结
做小型项目时，开发人员相对较少（1-3人），分支也比较简单，通常只有两个分支（Master和Dev），所有开发人员都在Dev分支开发，通过验收后合并至Master，Dev分支和Master分支差异不大，此时使用Git flow反而失去了灵活性，每次发布版本时打好tag即可。
当项目复杂，开发人员较多时，仅有两个分支就不够用了。
Git Flow 工作流：Git Flow 工作流为不同的分支分配一个明确的角色，并定义分支之间什么时候、如何进行交互，比较适合大型项目的开发。
总结：整体上来说，优点远远大于缺点，项目团队选型，可以自行考虑~
在实际工作过程中，往往是测试还在测试中，我们就开始新功能的开发，而且测试也是独立的进行。
还比如，你在开发某个feature时，又去支撑另一个feature，有或者多个feature并行开发同时测试也在进行等各种场景的情况。
所以一般情况下，我还是比较推荐git flow，也是比较主流的git工作流。
总之，项目比较大、人员稍微比较多（大于3个）的情况下，我就推荐git flow~
参考
07 | 工作流设计：如何设计合理的多人开发模式？
参考URL: https://time.geekbang.org/column/article/382342
Git 工作流程
参考URL: https://www.ruanyifeng.com/blog/2015/12/git-workflow.html
不熟练 Git 被优化了！腾讯是如何使用 Git 的 ？
参考URL: https://mp.weixin.qq.com/s/aaKQd3hJOjGfOZbe-jLcMA