别再推荐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可以确保你们不会把事情搞砸。

如果不使用Git Flow，那应该用什么？

这个问题我回答不了。并不是所有的分支模型都适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把我吓一跳。

关键在于你要问你的团队：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？你选择的分支模型最终都是为了让人们更容易地进行软件协作开发，因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些人在网上所声称的“成功的分支模型”。