假设您有两个已经单独开发的“主线”分支，当您进行它们之间的合并时，您希望将所有开发人员分开工作。
E.g。你希望你的C＃程序员合并C＃cope，而你的TSQL程序员正在合并存储过程。
我清洗所有开发人员以便能够看到仍然需要合并的内容以及彼此之间的结果合并，Mercurial可以帮助解决这个问题吗？
[我假设在他们被告知他们必须进行合并之后，有多个开发人员离开！]
正如我在评论中被问到的那样，这就是我认为我们进入这种状态的方式......
如果我在加入之前正确了解历史记录。一位大客户出现并表示“如果你将x，y和z添加到你的产品，我们会付给你很多钱，但我们不愿意承担你给我们任何风险的风险我们没有直接受益的变化（他们甚至将自己的一些程序员放在团队中检查他们没有得到其他变化）。
在这个大客户的工作进行的几年中，其他客户表示，如果我们没有添加，a，b和c，他们就不会购买产品。
大客户不愿意以某种方式（或能够被关闭）支付x，y和z的费用，而这种方式并没有为以不同方式使用它的其他客户破坏产品，并且大多数程序员都了解系统销售给大客户，因此没有人力（直到现在）来修复x，y和z，因此可以将它们提供给我们所有的客户。
（基本上是基于咨询收入来构建产品 - 事实上我们是由一家与大客户密切相关的公司带来的事实使政治变得更加复杂。）
当所有这一切开始时，产品没有太多的自动化测试覆盖率，代码库可以追溯到.net v1发布时，所有功能都在UI和源代码中很好地集成。
希望历史不会重演，但程序员很难在一个没有很多软件公司的城市中说“不”。我们现在正转向Mercurial，我想知道如果历史重演，我们如何应对Mercurial！ （我也开始质疑Mercurial是否完全与Perforce相比）
答案 0 :(得分：3)
是的，该方案有一个工作流程。
提前计划，在分支之前知道哪个分支将合并到之后，并确保定期合并。
示例：您具有默认分支，并创建一个功能分支，在某些时候应该合并回默认分支。定期从默认值合并到您的功能分支，以确保它是最新的默认更改。这会在此过程中产生较小的冲突。最后，您最后一次合并到您的功能分支，修复任何冲突，然后将其合并为默认值。
这样可以避免最后的“大合并”，并产生更容易管理的冲突。
答案 1 :(得分：1)
可能与您想要实现的目标最接近的是一次合并一个更改集。通过做很多小合并，这可以避免大爆炸合并。如果你在C＃开发者和TSQL开发者之间有明确的分离（听起来像你那样），那么你应该能够将每个变更集分配给正确的组。
这种方法的一大不利之处在于，您无法通过并行执行更改集来加快流程。
这种方法的一个重要优点是您可以在每次合并（或一小组合并）之后进行测试，从而更容易追踪破坏应用程序的更改。如果您目前没有强大的自动化测试套件，我强烈建议您先加强它。
答案 2 :(得分：1)
一种明智的方法可能是使用hg convert将存储库拆分成更小的部分（C＃部分，TSQL部分等），对那些更小和更细粒度的存储库执行合并，并且（如果保持原始存储库很重要）只要准备就绪，就可以将结果提交回原始存储库。