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

Question

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

在此期间，主干会看到主要的开发工作，并且可能会进行重构更改。

问题是需要有一个稳定的主干(以便错误修复的合并成功 - 如果代码已被提取到另一个方法，或移动到另一个类，通常不能成功)和在引入新功能时需要重构它。

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

但这意味着开发人员必须等待一段时间才能在主干上提交任何重构更改，因为这可能会破坏从分支到主干的后续合并。并且必须手动将错误从分支移植到主干是痛苦的。在我看来，这阻碍了发展......

你如何处理这种紧张局势？

谢谢。

Answer 1

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

我的偏好是让主干以正常速度运行而不是坚持下去，因为在发布时间在商业上很重要的环境中，我永远无法争论我们应该让代码稳定的情况(“什么，你的意思是你在不稳定的状态下释放它？”)。

关键是要确保在将错误迁移到主分支时转换为错误修复创建的单元测试。如果您的新代码更改确实只是重构，那么旧测试应该同样有效。如果您的更改不再有效，那么无论如何您都不能只移植您的修复程序，并且您需要有人认真考虑新代码流中的修复程序。

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

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

附录:我还应该提到，有必要将分支合并作为特定里程碑写入主分支的发布时间表。如果您有一群辛勤工作的开发人员在执行他们的工作来实现功能，请不要低估将您的分支组合在一起可能需要的工作量。