git flow工作流

git flow工作流

背景：

​ 在团队开发中，因为项目的众多，每个项目也都有不同的分支，往往会造成分支的混乱。比如我最近遇到了这样的情况，因为正在开发一个较为长期的项目，正改到一半，却派出来一个紧急的任务，不得不中断现有的任务。然后我拉了一个新的分支去做紧急的任务，等到紧急的任务做完后，另一个分支因为长期开发之前的任务导致代码长时间没有pull到最新的，后期合并的时候遇到了很多冲突。其实这样的情况是很不合适的，代码冲突合并后容易造成各种问题。

git flow介绍

​ 这个模型是在2010年构思出来的，现在已经超过10年了，而且是在 Git 诞生后不久。在这10年里，git flow在许多软件团队中变得非常流行。就目前而言，我们团队使用的也是git flow工作流。按功能来说，git flow可以分支为5种分支，从5 种分支的生命时间上，又可以分别归类为长期分支和暂时分支，或者更贴切描述为，主要分支和协助分支。

主分支

在采用 Git Flow 工作流的项目中，代码的中央仓库会一直存在以下两个长期分支：

• master
• develop

其中 origin/master 分支上的最新代码永远是版本发布状态。origin／develop 分支则是最新的开发进度。

当 develop 上的代码达到一个稳定的状态，可以发布版本的时候，develop上这些修改会以某种特别方式被合并到 master 分支上，然后标记上对应的版本标签。

协助分支

​ 上图是git flow的模型图，由上面的图我们可以看到主要有三个协助分支

• feature（Feature 分支用来做分模块功能开发，命名看开发者喜好，不要和其他类型的分支命名弄混淆就好，举个坏例子，命名为 master 就是一个非常不妥当的举动。模块完成之后，会合并到 develop 分支，然后删除自己。）
• release（Release 分支用来做版本发布的预发布分支，建议命名为 release-xxx。例如在软件 1.0.0 版本的功能全部开发完成，提交测试之后，从 develop 检出release-1.0.0 ,测试中出现的小问题，在 release 分支进行修改提交，测试完毕准备发布的时候，代码会合并到 master 和 develop，master 分支合并后会打上对应版本标签 v1.0.0, 合并后删除自己，这样做的好处是，在测试的时候，不影响下一个版本功能并行开发。）
• hotfix（Hotfix 分支是用来做线上的紧急 bug 修复的分支,建议命名为 hotfix-xxx。当线上某个版本出现了问题，将检出对应版本的代码，创建 Hotfix 分支，问题修复后，合并回 master 和 develop ，然后删除自己。这里注意，合并到 master 的时候，也要打上修复后的版本标签。）