别再推荐Git Flow了_文化 & 方法_George Stocker



 写点什么

写在前面

十年前，一篇名为《一个成功的 Git 分支模型》的文章将 Git Flow 推上了风口浪尖。在过去的十年里，无数个开发团队被这篇文章蒙在鼓里。说得严重一点，他们都被骗了。

文章的作者宣称他们已经成功地将 Git Flow 引入到项目中，但对于如何在项目中取得成功的细节却只字未提。

如果我们盲目地相信这篇文章所说的内容，那无疑是一个巨大的错误。我们必须承认，并不是所有的策略都适用于所有的情况、所有的人、所有的环境，而这个道理对于这个分支模型同样适用。

为了更有说服里一点，让我们来更深入地探究一下为什么我们应该让 Git Flow 分支模型葬身火海。

Git Flow 太复杂了

Git Flow 太复杂了，看看下面这张图，它已经很直观地说明了这一点：

这里有功能分支、发布分支、主干、开发分支、紧急修复分支和标签。在构建和发布过程中，你必须跟踪这些东西，还得理解它们，记得它们。

不仅如此，你还需要从头到尾跟踪哪个分支是用来干什么的，这对于你来说是一个很重的认知负担。我已经使用 Git 十年了，我甚至都不确定自己的脑力是否能够承担得了这些东西。

Git Flow 违背了分支的“短命”原则

在使用 Git 时，在同一个分支上开发代码的人越多，出现合并冲突的几率就越高。在使用 Git Flow 后，冲突几率会变得更高，因为还有三个其他的分支（具有不同的生命周期）会合并到开发分支上：功能分支、发布分支和紧急修复分支。现在，出现合并冲突的可能性不是线性的，而是呈三倍的数量增长。

虽然我不愿意说“担心出现合并冲突”是不想采用 Git Flow 分支策略的原因，但当所有这些分支聚集在一起，它们所引入的潜在复杂性是我们无法忽视的。如果你所在的企业提交代码的速度比较慢，或许没什么问题，但对于需要快速开发的企业或初创公司来说，情况就不一样了。

Git Flow 抛弃了 rebase

如果你要使用 Git Flow，就得放弃 rebase。rebase 取消了合并提交——也就是可以看到两个分支合并的地方。由于 Git Flow 的复杂性，你需要可视化跟踪分支，这意味着如果你想要看到来龙去脉，就不能使用 rebase。

Git Flow 阻碍了持续交付

持续交付是指开发团队的每次代码提交都会以自动化的方式（在实际当中是与主干合并）直接发布到生产环境中。看看这一团糟的 Git Flow，你倒是说说如何能够进行持续交付？

Git Flow 分支模型是基于可预测的长期发布周期，而不是基于每隔几分钟或几小时就要发布新代码的场景。这种发布方式的开销太大了。另外，持续交付的一个核心实践是通过修复的方式进行发布，而 Git Flow 将紧急修复作为一个单独的实体，并与其他开发工作分开。

Git Flow 无法应对多代码库

随着微服务的崛起，小型代码库的想法也得到了更多的推动。个体开发团队可以控制他们的代码库和工作流，他们可以控制谁能够向他们的代码库提交代码以及他们的工作流如何工作。

你有没有尝试过使用像 Git Flow 这样的分支模型，并希望每个人都能达成一致？这是不可能的。很快，系统就会出现不同版本的代码库，唯一知道一切的人是使用 YAML 来更新清单的人。你一不小心就很难知道“生产环境中究竟包含了哪些东西”。

Git Flow 无法应对大型单代码库

如果因为版本发布协调困难而无法使用多个微代码库，那为什么不使用一个单独的大型分支工作流，让所有的微服务团队都使用这个工作流？

这种方式在一小段时间内或许是可以的，直到一个开发团队要发布版本而其他团队还没有准备好。如果开发团队是独立的，微服务也是独立部署的，那就不能将你的工作流很好地与这种分支模型结合在一起。

谁应该（或不应该）使用 Git Flow？

如果你所在的公司采用了月度或季度发布周期，并且由一个团队负责并行开发多个项目，那么 Git Flow 可能是一个不错的选择。如果你所在的公司是一个初创公司，或者开发的是一个网站或 Web 应用程序，在一天内可能需要发布多个版本，那么使用 Git Flow 对你来说没有什么好处。如果你的团队规模很小（10 人以下），Git Flow 会给你的带来太多冗繁的工作。

但如果你的团队有 20 多人并行开发多个版本，那么使用 Git Flow 可以确保你们不会把事情搞砸。