Git Flows 之战

世界各地的软件工程师之间正在进行一场激烈的争论：我们的团队应该使用哪种 Git 流程？

有很多选择，包括：

图片由 GitLab 提供

微软等公司甚至也加入了他们自己的Git flow。

争议

这场争议似乎始于 2015 年那篇极具煽动性的文章《GitFlow 被认为有害》。在这篇文章中，一位名叫 Adam Ruka 的亚马逊开发人员抱怨道：

我认为 GitFlow 在很多方面都存在根本性的缺陷，而我观察人们尝试使用它的经历也进一步证实了这一点。而且，由于有一种更简单、同样（甚至更值得一提）更具表现力的方式来管理项目历史记录，我实在找不到再使用 GitFlow 的理由了。

他后来编写了前面提到的OneFlow，这或许让情况更加复杂。遗憾的是，OneFlow 包含许多可选组件，我认为这些组件会显著改变结果。例如，一个团队使用压缩和 rebase 与一个团队两者都不做，两者之间就截然不同。这真的是“一个流程”吗？

无论如何，GitFlow 确实受到了一些批评。想想平时中立的 GitLab 文档吧。它称 Git Flow “烦人”，充满“仪式感”，而且“太复杂”。

提出 GitFlow 的博客作者 Vincent Driessen 提供了这张图表来帮助说明该方法，但它经常被用作 GitFlow 是一个过度紧张的过程的证据：

Victor Driessen 提供

每个人对 Git 流程的期望似乎都不一样。一个团队想要一个非常干净、线性的提交日志。他们不在乎开发人员是否“重写历史记录”。Modern Coder 的这段视频演示了类似基于主干、rebase 的工作流程：

其他人永远不会想到“改写历史”，而且我敢肯定，如果可以的话，有些人会向《现代程序员》扔西红柿。

有些团队经常提交代码，还会在此基础上添加合并提交。他们的 git 仓库看起来就像树根蜿蜒交错，也就是所谓的“意大利面条分支”。

Reddit 著名帖子中的分支意大利面

那么这仅仅是选择毒药的情况吗？

您决定。以下列出了各种流程及其特点，可以帮助您确定最适合您团队的流程，或者帮助您定制您自己的新流程。