为什么更提倡基于主干开发

如今，像Git这样的分布式版本控制系统已经赢得了版本控制的“战争”。当分布式版本控制系统越来越受欢迎时，我经常会听到的是像使用像Git这样的版本控制系统来新建分支和分支的合并是多么容易。然而，我们却要更提倡基于主干的开发(Trunk-Based Development，TBD)，这是为什么呢？

通过基于主干的开发，所有开发人员都在一个分支上工作（例如“main”）。 你可能读过或听过Martin Fowler（https://martinfowler.com/articles/continuousIntegration.html）或Dave Farley（https://www.youtube.com/watch?v=v4Ijkq6Myfc）谈论它。基于主干的开发有很多好处，特别是在一个开创性的持续交付环境中。

相反，基于分支的模型鼓励开发人员为每个功能、错误修复或性能提升创建单独的分支。 尽管分支似乎是一种隔离修改和降低风险的合乎逻辑的方法，但有几个因素让我们更提倡基于主干的开发。

1、速度和效率

在基于主干的开发中，整个团队都在一个分支上工作。 该模型允许更快的集成和更少的合并冲突。 正如极限编程实践中建议的那样，这实际上就是“持续集成 (Continuous Integration：CI)”。

虽然现在当我们说持续集成时，我们的意思往往是“每次提交时都在团队服务器上运行构建和测试”，但持续集成的真正含义实际上是定期集成你的代码。 根据定义，生存在不同分支上的代码是不集成的。

这些分支存在的时间越长，将它们合并回主代码库的难度就越大。 在不受其他开发人员修改影响的单独分支上开发你的修复和改进似乎很快，但你仍然需要在某个时候支付合并的费用。 定期将小的修改集成到你的代码中通常比在较长时间后进行大合并更容易。

2、更高的代码稳定性

基于主干的开发鼓励频繁提交，这会促进更小且更易于管理的代码修改。

出于同样的原因，我们不希望从长期存在的分支中进行大合并 - 我们越长时间不管我们提交的代码，我们的提交与其他人的修改发生冲突的可能性就越大。

通过频繁拉取其他开发人员的修改，并频繁推送可以工作的代码修改，我们就可以知道代码库是稳定且可以工作的。

当然，这种“稳定且可以工作”的假设，通过我们的持续集成服务器更容易得到检查，因为持续集成可以编译和测试每一次的代码提交。

如果构建在任何时候中断，我们就必须停止代码的提交并专注于修复该构建。 当构建已经损坏时，持续的推送小而频繁的代码不会给任何人带来任何好处。

在分支模型中，大型且不频繁的合并很有可能会引入错误，由于更改的规模之大，这些错误很难识别和解决。

你有没有在把主干的代码合并到你的分支的时候，因为其他人将他们的代码合并到主干，导致你的代码就不能工作了这么情况？

当你进行了一大堆修改而其他人进行了一大堆不同或重叠的修改时，可能会导致需要花费大量时间来定位测试失败或程序未按预期方式工作的原因。

3、 提高团队合作

团队成员之间分享知识的最佳编程方式是结对编程。 当然并不是每个人都是这样做的粉丝或有能力这样做（尤其是现在越来越多的人在远程工作）。

如果你们不结对，那么至少你们希望使用相同的代码。如果你们都在自己的分支里写代码，那就意味着你们不在合作。这时候你们会竞争。看谁能最快地完成代码。以避免被其他人的代码修改踩踏。

如果你们都在同一个分支上工作，你往往会更好地了解所做的修改。 这种方法促进了更好的团队协作和知识共享。

相反，分支会创造一个孤立的工作环境，让你们都独立工作，从而导致团队内部的知识鸿沟。

4、改进的持续集成和交付 (CI/CD) 实践

Dave Farley 的书“Continuous Delivery”以及他的博客文章和视频围绕“基于主干的开发本质上与持续集成和持续交付 (CI/CD) 实践兼容”的思路进行了论证。

在基于主干的模型中，持续集成变得更加直接，因为你的代码经常提交到主干，而这是你的 持续集成环境正在运行构建和测试的分支。那里的任何故障都会被及时发现并解决，从而减少严重故障的风险。 通常定位到是哪些变化导致了问题是很容易的。如果问题不能立即解决，你可以很容易回溯到导致问题的特定修改。

我们应该都知道快速反馈循环的重要性——当你更快地发现问题时，你可以更快地找到原因，并更快地解决问题。这样可以提高软件的质量。

持续交付也在基于主干的开发环境中蓬勃发展。成功的持续交付取决于是否拥有始终处于可部署状态的代码库的能力。

基于主干的开发方法通过促进频繁的提交、频繁的集成和对所有这些集成的测试来确保这一点。在任何时候引入的少量修改使软件更容易部署和测试。

相比之下，使用分支模型实现有效的CI/CD可能更加复杂和耗时。合并和测试来自不同分支的代码可能会带来延迟和潜在的错误，这也将消除拥有构建管道所带来的好处。

5、减少技术债

长时间的分支通常会导致“合并地狱”，一个分支(比如“main”)和另一个分支(比如你的功能特性分支)之间的差异如此之大，以至于合并成为一场噩梦。

这可能会导致技术债，因为你可能会求助于快速修复来解决合并冲突，或者接受来自于IDE的解决合并的建议，但你却并不完全理解这些建议。

在基于主干的开发中，频繁的合并和较小的修改使管理和减少技术债的积累变得更加容易。

总结

基于主干的开发具有明显的优势，很多团队采用了这种方法并亲身体验过它们的优势。但是，它需要开发团队内部一种心智和文化。

你需要经常将其他开发人员的修改合并到你自己的代码中。你需要经常提交小的修改，这要求你只修改代码的一小部分并进行增量修改，这可能是一个很难养成的习惯。

基于主干的开发，以一种有纪律的方式进行，它简化了开发过程，增强了团队协作，提高了代码稳定性，支持高效的 CI/CD 实践，并可能促使更少的技术债。

如果你一直在使用基于分支的模型，虽然适应这种方法可能具有一定的挑战性，但长期收益是值得的！

参考原文：https://trishagee.com/2023/05/29/why-i-prefer-trunk-based-development/