0

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

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

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

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

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

4

2 回答 2

0

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

于 2013-08-23T05:11:06.207 回答
0

对于长期工作

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

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

先决条件

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

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

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

业务逻辑（TBT！！！）

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