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

Question

我们运营基于干线的开发。我们最新和最好的代码不断集成到我们的主干中，直到我们准备好让它成为UAT。在那个阶段，我们从UAT的主干创建一个候选版本分支，并在主干中继续新的开发。一旦该候选版本通过UAT，它将被标记并发布到Live，并且从该标签创建的维护分支将一直存在，直到下一个主要（UAT）发布。

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

我们都知道这一点，但有时合并会被遗漏，而且我们已经遇到过在Live中修复过的错误再次重新浮出水面的情况，因为修补程序未应用于所有必需的分支（主干和候选版本）

我们已经开始在我们的提交评论中引用其他分支的提交（基本上是我们自己的糟糕的合并信息），以便跟踪它。

然而有没有办法让我们绝对确保维护分支的所有提交都合并到trunk和release候选者，并且所有提交候选版本的提交都会合并到trunk？ < / p>

Answer 1

由于VCS无法发现错误修复和正在进行的开发之间的区别，简短的回答是没有办法100％确定，一个有开发人员检查清单的良好跟踪系统可能有所帮助但是甚至威胁要开枪或射击罪犯并不能确保不会发生。 实际上，这样做会减少重复违规者的行为！

Answer 2

永久性工作

• 将维护分支的所有提交合并到主干并释放候选人
• 将候选版本的所有提交合并到trunk

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

<强>先决条件

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

此外，非强制性（见下文）

• 预提交挂钩，可以在不更改挂钩代码的情况下阻止来自自定义用户列表的提交

商业逻辑（TBT !!!）

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