轻松掌握Git工作流：Git Flow实践指南与高效协作秘诀

自从 Linux 之父 Linus Torvalds 对当时的版本控制工具感到不满，亲自动手创造了 Git 以来，Git 已经逐渐在版本控制领域占据了主导地位。不论你的代码仓库托管在 GitHub 还是 GitLab，不论你用的是 SourceTree、GitKraken 这样的图形界面，还是喜欢直接敲 Git 命令，这些都没问题。因为 Git 带来的便捷性和高效性，我们已经越来越离不开它了。

然而，随着项目规模的增长和协作人数的增加，有些人发现 Git 用起来似乎越来越复杂：有时候合并时会遗漏文件，有时明明删掉的文件又重新出现，甚至每次合并都要解决几十上百个冲突。这时，你可能会怀疑 Git 的能力，心里嘀咕：“这 Git 压根儿就驾驭不了咱们这么庞大的项目。“

幸好，这个世界上只要有新的好工具，就会有一群懒惰的工程师开始想方设法地让自己的生活好过一点。Vincent Driessen 就是这种人，于是他根据自己的经验，将工作中经常会遇到的场景逐一整理，根据 git 的特性，制定了一套工作规范，也就是本文的主角：Git Flow。

上图大家应该不陌生吧？你心里一定想说：“这张图我看到都会背了，问题是每次合并还是很痛苦啊！”

我们省去理论介绍的部分，直接从工作中一个平凡无奇的早晨开始，大家跟着叙述场景，一起看看 Git Flow 到底怎么帮助我们梳理工作流程，节省时间的。

假设，你们已经有了 master 和 develop 两个常驻型分支，其他分支都没有。早上你泡好咖啡，从你的座位上坐下，决定好今天要为这个项目加上一个发 email 的新功能，这时，你应该创建一个新的特性分支，并命名为add_email。

图中粉红色圆圈的就是你新建的分支，按照 GitFlow 的规定，它会被归类在一个名为feature的目录下，比如``feature/add_email，这样做纯粹是为了方便识别和管理。

接下来你就开始开发，开发与测试花了三天，结束后你就要删除这个分支，于是你合并回 develop，一切又如一开始那样和谐，世界上只剩 develop 和 master 两个分支。

当然，世事不可能永远如我们想的那么美好，项目越来越大，就会有越来越多的功能在同步开发，这时候怎么办？

左图这样同时有几个feature同时在开发的场景多了去了。但是 Git Flow 告诉我们不用操心，尽管开发自己的功能便是，但是你一定要注意一点，开发测试完自己的功能就一定要赶快合并回主线，并删除这个分支。

记住，无论何时，都要让未合并的feature分支越少越好，分支生命周期越短越好。这件事情对帮助 develop 的稳定性有莫大的好处。

请记住：feature 分支的生命周期不应过长。如果这个功能分支涵盖的业务太多太复杂导致生命周期太长。请找你的项目经理商量，试着再多拆分成几个独立的小 feature。

终于到了上线的时候，首要任务是确定版本号。怎么定版本号这里不展开，总之，版本号确定后，接下来就是开启release分支了。

黄色为 develop 分支，蓝色为 master 分支

图中绿色的点代表了release分支短暂的一生。一旦开启release分支，就进入了发布前的最终测试阶段。

也有人将release分支仅视为进入master之前的缓冲区，所有的最终测试都是针对master进行的，一旦发现问题就新开分支修复。

这两种做法各有优缺点，我认为都挺好，但有一条必须严格遵守

release 分支只能修 bug，不能添加新功能。

release 分支只能修 bug，不能添加新功能。

release 分支只能修 bug，不能添加新功能。

一旦开了release分支，就只能修复 bug，不能再加新功能。 这一点非常重要，因此重复三遍。实践中，总有人喜欢在 bug 修复中夹带新功能，但要知道，此时往往缺乏全面回归测试的支持。这相当于在即将发布的版本中，悄悄植入未经充分验证的新功能，等同于埋下了随时可能爆炸的炸弹。

一旦在正式环境中发现问题需要修复，这时就需要使用hotfix分支了。

黄色为 develop 分支，蓝色为 master 分支

图中的红色圆圈就是hotfix，它从master分支切出，结束时同样要合并到master，并顺便同步到develop，流程和release分支类似。

实际上，我们在处理hotfix时，也要像对待release一样： 开分支的同时就要确定版本号，只能修复 bug，不能夹带新功能。 理由很简单，hotfix和release跟正式环境运行的代码版本基本是一样的，因此对它们的谨慎程度也应该相同。而且由于hotfix通常紧急，更难以进行全面的回归测试（即使有回归测试，也不能完全保证无误）。因此，为了避免更大的损失，一定要慎之又慎

测试完毕，hotfix，重新上线，同时修复了develop，世界又回到了最初简单的状态，只剩下develop和master两个分支。

我认为，越是庞大的产品，越是要有简单的架构；越是复杂的工作，越是要用简单的方法处理。有了 gitflow，你可以有一套简单的标准去套用工作上的场景。因为这套工作流程比较简单，所以你并不应该等到事情变得复杂才来解决。请容我换个方式再讲一次：

gitflow 的目的是要用简单的流程解决工作上的问题，所以不要把问题放到很复杂了才想要来解决。

最后，总结一下文中提到的原则：

• feature 分支的生命周期不宜过长，最多最多不要超过一个迭代周期

• 如果一个feature 分支包含的功能太多太复杂，开发周期太长，应该拆成几个小的feature

• 发版前必须切出release分支，预上线的测试版本一定要和实际上线的版本一致

• release分支上只能做 bug 修复。

• hotfix和release分支开启时即要决定版本号，且同样只准修复 bug，不可加入新功能。

• 经常存在的分支只有两个：develop 与 master