Git Flow 被抛弃的 8 大理由

在过去的十年里，无数团队被这篇博文蒙在鼓里。但我敢说，这篇文章撒谎了。

如果你读过这篇博文，你就会注意到，尽管作者声称他们在项目中成功使用了 Git-flow ，但却故意避开了让项目成功的细节。

很多人会相信看到的博文，这其实是错误的。并非所有的策略都适用于所有情况，这是一个真理。我将同样的逻辑应用于这个分支模型。

好吧，你们当中的一些人不相信这个真理，所以让我们深入研究为什么 Git-flow 分支模型应该葬身火海。

Git-flow 的界面很复杂

Git-flow 特别复杂，甚至在考虑微服务或连续交付之前就已经如此了。下面的图片直观地展示了这一点：

这里有特性分支、发布分支、master 分支、dev 分支、一个紧急修复分支和 git 标记。这些都是在构建和发布过程中必须跟踪、理解和考虑的事情。

更重要的是，你还需要随时跟踪每个分支，这造成了很高的认知负荷。我已经使用 git 10 年了，我甚至不确定自己是否能在精神上跟上这里的发展。

在 git 中，随着在某个分支上工作人数的增加，发生合并冲突的次数将大大增加。在 Git-flow 中，这个数字增加得更多，因为还有三个具有不同生命周期的其他分支合并到开发中：特性分支、发布分支和紧急修复。合并冲突发生的可能性并不是线性变化的，它可能会使合并冲突的概率增加三倍。

这太糟糕了。

虽然我不敢说不采用 Git-flow 这样的分支策略就可以避免合并冲突，但是当所有这些分支组合在一起时，引入的潜在复杂性太大了，无法忽略。如果你们公司的代码提交速度很慢，那就没关系。但是对于任何快速迭代的组织或初创企业来说，情况并非如此。

重新定位合并节点是一个复杂的话题，但它很重要。如果你使用 Git-flow，你将不得不放弃 rebase。记住，rebase 取消了合并提交，你再也看不到两个分支组合在一起的节点。由于 Git-flow 的视觉复杂性，你需要可视化地跟踪分支，这意味着如果你想解决问题，就不需要 rebase。

持续交付是一种实践。在这种实践中，团队以自动化的方式直接发布到生产中（实际上是合并到 master）。看看混乱的 Git-flow，你能解释一下如何持续地交付吗？

整个分支模型是根据可预测的、长期的发布周期进行预测的。如果每隔几分钟或几小时发布一次新代码，开销就太大了，更不用说 CD 的中心实践之一是向前滚动修复。Git-flow 将修补程序视为一个单独的实体，需要小心地控制，并与其他工作分离开来。

随着微服务的出现，micro-repo 的理念也得到了更多的推动，各个团队可以控制他们的存储库和工作流，他们还可以控制谁进入了他们的存储库以及其工作流是如何工作的。

你有没有尝试过这样一个复杂的分支模型：它有多个团队，并且希望它们都在同一个页面上？这是不会发生的。很快，这个系统就变成了不同 repo 的不同版本的一个清单，只有敲出 YAML 来更新清单的人知道所有东西在哪里。如果你不够细心，「在生产什么」就变成了一个存在主义的问题。

因此，如果由于协调发布的困难而取消了 micro-repo，那为什么不让所有微服务团队都遵守一个大的发布分支工作流呢？

这个过程大约持续 3.2 秒。如果团队是独立的，micro-repo 应该是独立部署的，这样就不能很好地将你的工作流程与你在 mono repo 中创建的集中式分支模型联系起来。

如果你的团队每月或每季度发布一次，并且是一个并行处理多个发布的团队，那么 Git-flow 可能是一个不错的选择。如果你的团队是一个初创企业，或者是一个面向 internet 的网站或 web 应用程序，同一天可能发布多个版本，那 Git-flow 对你来说就不合适了。如果你的团队是一个不到 10 人的微型团队，Git-flow 会给你的工作带来太多的规矩和开销。

另一方面，如果你的团队有 20 多人进行并行发布，那么 Gitflow 可以确保不会把事情搞砸。

我不能回答。并非所有分支模型都适用于所有团队和所有情况。如果你练习 CD，你需要一些尽可能简化过程的东西。

关键在于，团队需要反思：这个分支模型将帮助我们解决哪些问题？会产生什么问题？这种模型将鼓励什么样的发展？我们想鼓励这种行为吗？使用分支模型的最终目的都是方便软件开发过程中的合作，因此，需要考虑使用它的特定人群的需求，而不是互联网流传的「成功」的东西。