提供新版本时，我们的政策是在VCS中创建分支并将其交给我们的质量检查团队。当后者发出绿光时，我们标记并释放我们的产品。该分支将保留(仅)错误修复，以便我们可以创建技术版本。这些错误修复程序随后将合并到主干中。
在此期间，主干将看到主要的开发工作，并且可能会进行重构更改。
问题在于，在拥有稳定的主干(以使错误修复程序合并成功-如果代码已被例如提取到另一种方法或移到另一类中通常无法实现)之间存在压力。引入新功能时需要对其进行重构。
我们的策略是在经过足够的时间并且分支足够稳定之前，不进行任何重构。在这种情况下，可以开始对中继进行重构更改，并且必须在中继和分支上手动提交错误修复。
但这意味着开发人员必须等待相当长的时间才能在干线上提交任何重构更改，因为这可能会破坏从分支到干线的后续合并。而且必须手动将错误从分支移植到主干是很痛苦的。在我看来，这阻碍了发展……
您如何处理这种紧张局势？
谢谢。
最佳答案
这是一个实际的实际问题。如果您需要支持多个版本并为每个版本分支，则情况会变得更糟。更糟糕的是，如果您也拥有真正的研发部门。
我倾向于允许主干以正常速率运行，而不是坚持不停，因为在商业发布时间很重要的环境中，我永远都不会争辩说我们应该让代码稳定下来(“这是什么意思？以不稳定状态释放它？”)。
关键是要确保在将错误迁移到主分支时跨过为错误修复创建的单元测试。如果您对新代码所做的更改确实只是在重构，那么旧测试应该同样有效。如果您所做的更改不再有效，那么您无论如何都不能移植您的修复程序，而您需要让别人认真考虑一下新代码流中的修复程序。
在解决了此类问题很多年后，我得出结论，您可能至少需要4个代码流才能提供适当的支持和覆盖，并需要一组相当严格的流程来管理它们之间的代码。这有点像能够绘制4种颜色的 map 的问题。
我从来没有找到关于这个主题的真正好的文献。它将不可避免地链接到您的发布策略以及您与客户签署的SLA。
附录:我还要提到，有必要将合并的分支作为特定的里程碑写入主分支的发布时间表。如果您有一群努力工作的开发人员执行其工作实现功能，请不要低估将分支机构整合在一起可能需要的工作量。
关于version-control - 您如何处理重构和合并需求之间的紧张关系？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/200757/