我们如何确保维护分支上的错误修复合并回主干？

Posted 2023-04-13

【中文标题】我们如何确保维护分支上的错误修复合并回主干？

【英文标题】：How do we ensure that bug fixes on maintenance branch are merged back to trunk?

【发布时间】：2013-08-22 16:59:30

【问题描述】：

我们经营基于主干的开发。我们最新最好的代码不断地集成到我们的主干中，直到我们准备好将其 UAT 化。在那个阶段，我们从主干为 UAT 创建一个发布候选分支，并且新的开发继续在主干中进行。一旦这个候选版本通过了 UAT，它将被标记并发布到 Live，并从该标记创建一个维护分支，该分支将持续到下一个主要 (UAT'd) 版本。

问题是，如何处理错误修复的合并。如果在 UAT 期间修复了维护分支上的错误，则应将此代码修复合并到主干和候选发布版。如果在 UAT 期间修复了 UAT 错误，则应将此代码修复合并到主干。

我们都知道这一点，但有时会错过合并，并且我们遇到过在 Live 中修复的错误再次出现的情况，因为修复并未应用于所有必需的分支（主干和候选发布） .

我们现在已经开始在我们的提交 cmets（本质上是我们自己可怜的 mans 合并信息）中引用对其他分支的提交以跟踪这一点。

但是我们有什么方法可以绝对确保所有对维护分支的提交都合并到主干和候选发布，并且所有对发布候选的提交都合并到主干？

【问题讨论】：

如果您有一个相当标准的开发周期，那么您应该安排它们之间的合并。通常每两周左右对我的团队来说似乎是最佳时机。

如上所述，我们的过程是将各个提交合并回主干（和发布候选），而不是对分支进行完全合并 -> 让每个开发人员对自己的修复负责。然而，也许在发布前一天冻结维护分支并将完整的分支合并回主干和发布候选是捕获任何遗漏的好方法。我猜颠覆会足够聪明，只能合并被遗忘的内容（假设有好的合并信息）。

正确。我会添加至少另一天的缓冲区（这样您可以在发布前 两天 天合并），这将使您有足够的时间来管理奇怪的（但完全可以解释的）合并更改。

【参考方案1】：

由于 VCS 无法发现错误修复和正在进行的开发之间的区别，简短的回答是没有办法 100% 确定，一个为开发人员提供检查列表的良好跟踪系统可能会有所帮助，但即使威胁要开枪或枪杀罪犯也不能确保它不会发生。 实际上这样做可以减少屡犯者！

【讨论】：

嗯，维护分支和候选发布版本上的每个提交都必须合并到主干，所以我们不必区分提交。之前已经发出过通讯，我们已经澄清并再次发送（备份了维基页面），但我们仍然遇到问题 -> 有些人忘记了。

【参考方案2】：

对于长期工作

将维护分支的所有提交合并到主干和候选发布 将发布候选的所有提交合并到主干

您可以使用（显然！！！）特殊的提交后挂钩

先决条件

主干 + RC 分支的工作副本（在 SVN 服务器主机上）

另外，不是强制性的（见下文）

预提交钩子，它可以阻止|通过自定义用户列表的提交，而无需更改钩子的代码

业务逻辑（TBT！！！）

如果提交影响任何受监控的分支（使用svnlook dirs-changed 执行此任务）：需要合并到（已知）目标。此时您可以拥有未来强制合并的目标列表 尝试合并 svn up WC 目标 尝试合并：svn merge <options> --dry-run 如果测试合并没有冲突 - 在 WC 中执行合并并提交合并集，返回退出代码“OK”并完成挂钩 如果发现合并冲突，因此必须在合并中进行人工干预，您可以选择任何路径： 通知提交者有关问题和他等待的下一个操作（合并与解决冲突） 通知提交者有关问题和他的下一个等待操作，并以某种方式将提交者的用户名放入禁止列表中以进行预提交挂钩（禁止未来提交，除了手动合并集到目标中） 如果提交从被阻止的用户合并到 TARGET(s) - 将用户从禁令中删除