为什么你应该避免复杂的分支

当我们谈论分支时，我们通常使用“长期存在的分支”和“短期存在的分支”这样的术语，它们通常是按时间来区分的。我认为这种方式有些误导。分支是关于变更的，而变更很难用时间来衡量。开发人员可以花8小时编写大量代码并进行重构，并尝试在1天内合并这个非常复杂的分支。如果仅按时间来衡量，它仍然被视为“短期存在的分支”。相反，如果他们有一个只修改了一行代码的分支——例如，更新了代码所依赖的包——但由于团队必须解决一些关于该变更的架构问题，这个分支持续了3周，从时间角度来看，这将是一个“长期存在的分支”，即使将这些更改重新基于主分支之上非常简单。

时间似乎不是区分良好和不良分支实践的最佳标准；它是复杂性和时间的结合体。从你创建分支的基准分支到尝试将更改合并回去的过程中，基准分支发生的更改越多，合并这些更改就越困难。复杂性可以来自一个非常复杂的合并，或者来自多个开发人员合并了许多小的更改。为了避免合并冲突，许多团队试图在合并之前完成一个特性的工作。当然，这样会导致更复杂的更改，进而使得其他特性也很难合并——这就是所谓的“合并地狱”，即在发布之前，所有特性必须集成到新版本中。

为了避免“合并地狱”，你应该定期拉取主分支的最新版本。只要你能够毫无问题地合并或重新基准（rebase），那么将你的分支集成回去就不会有问题，但如果你的更改变得过于复杂，对其他开发人员来说可能会成为一个问题，因为他们在你将更改合并回主分支时，可能会遇到问题。因此，你应该在更改的复杂性超过某个程度之前将其合并。复杂性的程度很大程度上取决于你修改的代码，以下几点是你需要考虑的因素：

我认为这也是人们倾向于用时间来衡量而不是复杂性的原因——因为没有一个很好的衡量复杂性的标准。所以，作为经验法则：如果你在处理一个更复杂的特性，你应该至少每天将你的更改合并回主分支一次；但如果你的更改很简单，长时间保持分支或拉取请求开放也是没问题的。记住，关键不在于时间，而在于复杂性！