Version control 如何处理重构和合并需求之间的紧张关系？

交付新版本时，我们的政策是在我们的VCS中创建一个分支，并将其交给我们的QA团队处理。当后者开绿灯时，我们就贴上标签并发布产品。该分支将接收（仅）错误修复，以便我们可以创建技术版本。这些bug修复随后会合并到主干上

在此期间，主干可以看到主要的开发工作，并且可能会受到重构更改的影响

问题在于，在需要一个稳定的主干（以便错误修复的合并成功——如果代码被提取到另一个方法或移动到另一个类，则通常无法成功）和引入新功能时需要重构主干之间存在着紧张关系

我们的政策是在足够的时间过去并且分支足够稳定之前不进行任何重构。在这种情况下，可以开始对主干进行重构更改，并在主干和分支上手动提交错误修复

但这意味着开发人员在主干上提交任何重构更改之前必须等待相当长的时间，因为这可能会中断从分支到主干的后续合并。必须手动将bug从分支转移到主干是一件痛苦的事情。在我看来，这阻碍了发展

你如何处理这种紧张关系

---

谢谢。

这是一个真正的实际问题。如果您需要支持多个版本，并且每个版本都有分支，那么情况会变得更糟。更糟糕的是，如果你也有一个真正的研发部门

我的偏好是允许主干以正常速率运行，而不是保持不变，因为在一个发布时间在商业上非常重要的环境中，我永远无法论证我们应该允许代码稳定（“什么，你的意思是你在不稳定的状态下发布了它？”）

关键是要确保为bug修复创建的单元测试在bug迁移到主分支时进行了转换。如果您的新代码更改实际上只是重新分解，那么旧的测试应该同样有效。如果您的更改已不再有效，那么在任何情况下都不能只移植您的修复，您需要有人认真考虑新代码流中的修复

在处理这类问题好几年之后，我得出结论，您可能至少需要4个代码流来提供适当的支持和覆盖，以及一组相当严格的过程来管理跨它们的代码。这有点像能用4种颜色绘制任何地图的问题

我从来没有找到关于这个问题的真正好的文献。它将不可避免地与您的发布策略以及您与客户签署的SLA相关联

---

附录：我还应该提到，有必要将分支合并作为特定里程碑写入主分支的发布计划中。如果您有一群辛勤工作的开发人员在执行功能，那么不要低估将分支整合起来可能需要的工作量。

在我工作的地方，我们一直在主分支中进行重构。如果合并变得棘手，只需在临时基础上处理它们，它们都是可以做到的，但有时需要一些时间。

也许我们的问题来自这样一个事实，即我们的分支必须有相当长的使用寿命（最多18个月），并且必须对它们进行许多修复

---

确保我们只从极其稳定的代码中分支可能会有所帮助，但不会那么容易…：（

我认为可以通过在你的发展过程中添加以下成分来处理这种紧张关系：

连续积分

自动功能测试（我假定您已经使用单元测试计数）

自动递送

在持续集成中，每次提交都意味着一个构建，在这个构建中，所有单元测试都会被执行，如果出现任何错误，您会受到警告

通过自动功能测试，您可以在点击按钮时测试应用程序。通常，由于这些测试需要更多的时间，因此每晚都会运行这些测试。 这样，版本控制的经典角色开始失去重要性。您不会根据版本及其成熟度来决定何时发布，更多的是业务决策。如果您已经实施了单元和功能测试，并且您的团队正在提交测试过的代码，head应该始终处于可以发布的状态。Bug are不断发现、修复和发布，但这不再是周期性的过程，而是连续的过程

你可能会有两种类型的批评者，因为这意味着改变一些根深蒂固的做法。首先，持续交付的范式转变对管理者来说似乎是违反直觉的。“难道我们不冒着发布一个主要错误的风险吗？”如果你看一看Linux或Windows发行版，这正是他们正在做的：将发行版推向客户。而且，由于你使用了一套自动化测试，危险就进一步减少了

接下来是QA团队或部门。（有些人会认为问题在于他们自身的存在！）他们通常不喜欢自动化测试。这意味着学习新的，有时是复杂的工具。在这里，最好的方法是通过这样做来宣讲。我们的开发团队开始致力于持续集成，同时编写一套功能测试。当QA团队看到工具在运行时，很难反对它的实施

---

最后，第四点是，我所描述的过程并不像在开发过程中添加3个要素那样简单。它意味着软件开发方式的深刻变化。

在我工作的地方，我们创建了临时的、短期的（le