别再推荐Git Flow了
极客时间编辑部
讲述：初明明大小：4.34M时长：04:44
近日，InfoQ 中文站编译了乔治·斯托克（George Stocker）的一篇文章，斯托克称，十年前，一篇名为《一个成功的 Git 分支模型》的文章将 Git Flow 推上了风口浪尖。在过去的十年里，无数个开发团队被这篇文章蒙在鼓里。因为文章的作者宣称他们已经成功地将 Git Flow 引入到项目中，但对于如何在项目中取得成功的细节却只字未提。斯托克建议将 Git Flow 分支模型葬身火海，并列出以下几个原因。
1. Git Flow 太复杂了
Git Flow 太复杂了，看看下面这张图，它已经很直观地说明了这一点：
这里有功能分支、发布分支、主干、开发分支、紧急修复分支和标签。在构建和发布过程中，你必须跟踪这些东西，还得理解它们，记得它们。
不仅如此，你还需要从头到尾跟踪哪个分支是用来干什么的，这对于你来说是一个很重的认知负担。
2. Git Flow 违背了分支的“短命”原则
在使用 Git 时，在同一个分支上开发代码的人越多，出现合并冲突的几率就越高。在使用 Git Flow 后，冲突几率会变得更高，因为还有三个其他的分支（具有不同的生命周期）会合并到开发分支上：功能分支、发布分支和紧急修复分支。现在，出现合并冲突的可能性不是线性的，而是呈三倍的数量增长。
当所有这些分支聚集在一起，它们所引入的潜在复杂性是人们无法忽视的。如果你所在的企业提交代码的速度比较慢，或许没什么问题，但对于需要快速开发的企业或初创公司来说，情况就不一样了。
3. Git Flow 抛弃了 rebase
如果你要使用 Git Flow，就得放弃 rebase。rebase 取消了合并提交——也就是可以看到两个分支合并的地方。由于 Git Flow 的复杂性，你需要可视化跟踪分支，这意味着如果你想要看到来龙去脉，就不能使用 rebase。
4. Git Flow 阻碍了持续交付
持续交付是指开发团队的每次代码提交都会以自动化的方式直接发布到生产环境中，也就是与主干合并。 而使用 Git 时，合并冲突的几率是成倍提高的，阻碍了持续交付。另外，Git Flow 分支模型是基于可预测的长期发布周期，而不是基于每隔几分钟或几小时就要发布新代码的场景，这种发布方式的开销太大了。另外，持续交付的一个核心实践是通过修复的方式进行发布，而 Git Flow 将紧急修复作为一个单独的实体，并与其他开发工作分开。
5. Git Flow 无法应对多代码库
随着微服务的崛起，小型代码库的想法也得到了更多的推动。个体开发团队可以控制他们的代码库和工作流，也可以控制谁能够向他们的代码库提交代码以及工作流的工作方式。
你有没有尝试过使用像 Git Flow 这样的分支模型，并希望每个人都能达成一致？这是不可能的。很快，系统就会出现不同版本的代码库，唯一知道一切的人是使用 YAML 来更新清单的人。你很难知道“生产环境中究竟包含了哪些东西”。
6. Git Flow 无法应对大型单代码库
如果因为版本发布协调困难而无法使用多个微代码库，那为什么不使用一个单独的大型分支工作流，让所有的微服务团队都使用这个工作流？
这种方式在一小段时间内或许是可以的，直到一个开发团队要发布版本而其他团队还没有准备好。如果开发团队是独立的，微服务也是独立部署的，那就不能将你的工作流很好地与这种分支模型结合在一起。
谁应该（或不应该）使用 Git Flow ？
如果你所在的公司采用了月度或季度发布周期，并且由一个团队负责并行开发多个项目，那么 Git Flow 可能是一个不错的选择。如果你所在的公司是一个初创公司，或者开发的是一个网站或 Web 应用程序，在一天内可能需要发布多个版本，那么使用 Git Flow 对你来说没有什么好处。如果你的团队规模很小（10 人以下），Git Flow 会给你带来太多冗繁的工作。
你选择的分支模型最终都是为了让人们更容易地进行软件协作开发，因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些人在网上所声称的“成功的分支模型”。
以上就是今天的内容，你使用过 Git Flow 吗？体验如何呢？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
四道杠的红领巾不使用gitflow，那么推荐使用什么呢？16
AceHan分支模型需要考虑到使用者的需求，而不是盲目听信某些人在网上所声称的“成功的分支模型”。 这句话说的好。去年我尝试过在团队中推 Git Flow，也搬出了这张图，跟两个负责人分别讲过之后，一个闭而不语，估计没太听懂，而另一个直接表示太复杂，最后不了了之了。4
Geek_516ab1我也不喜欢过于复杂的分支。但个人觉得这文章的推导有很大的问题，1.对git模型认知是必须的，git flow 模型理解不了，那你也不要用git了员。2.对于冲突，你一个文件要写多大?项目分配的不好，代码写得烂，往往才是冲突爆表的原因 3. 对于小项目的管理，submodule 好用得很。3
weineel
学习git flow 至少能对git 的使用有更深刻的认识。并不一定要用在项目中。2
CoolPanda对于一些手动管理代码的项目，git flow可以作为一个不错的参考，实际使用起来，如果发现不适合自己，自然就会做变动，或者寻求更好的方法。2
天降神经病Git Flow有属于它自己的场景，没必要用这种标题吧！还有这文章阉割版，既然说不推荐用Git Flow，那我们要用什么啊。←_←1- 驹哥模型可以化简使用，也可以扩展复杂了使用。那么到底是人为问题还是模型有问题？模型的介绍者有义务从0到1到100地事无巨细地介绍每一种应用场景对应的化简和扩展吗？智力不够就不要干这行。1
priapus就我目前连git都掌握不熟的人来说，git flow简直就是想听天书那样子～1
耿老的竹林用gitlab的时候，帮助文档里有一个章节就是关于gitflow的。里面介绍了经典的git flow, github流程，以及gitlab流程，可以借鉴看一下。1
小斧你选择的分支模型最终都是为了让人们更容易地进行软件协作开发，因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些人在网上所声称的“成功的分支模型”。1
收起评论