合并多个Mercurial分支

我有一群开发人员使用分支修复他们的bug。我的需求：自动化（或有没有办法）将所有这些分支合并到一个主分支“default”的最佳方法是什么

谢谢

注意：这是我的观点，这里可能有多种观点，但至少要理解我的观点，并决定你想要不同的观点

首先，这里缺少了一些东西，我认为从长远来看，这会给您带来工作流问题

合并不是应该跳过或委托给其他人的事情，在这些分支中工作的开发人员应该自己合并。他们，可能只有他们知道自己做了什么，以及如何解决合并冲突

无论如何，全自动操作是行不通的

以下是开发人员应该使用的工作流（在我看来）

例如，每天早上，分支上的开发人员应该定期检查构建服务器，以确保默认分支构建成功。如果是这样（而且应该是这样！），它们将从默认分支向下合并到自己的分支中

这有三大好处：

他们在自己的分支中总是有最新的代码，并且不会陷入在其他分支中已经修复的已知bug的工作中

它们不断地处理来自其他分支的合并冲突，而这些冲突很小，并且这些更改在开发人员的头脑中仍然是新鲜的

由于您每天都要处理合并冲突（如果有），当您到达该分支的生命周期结束时，它几乎完全与默认分支合并，因此将其合并回默认分支所涉及的工作现在应该是廉价的，如果不是免费的

在某个时刻，他们会被读取以将他们的工作集成回默认分支（或者定期地，即新功能的部分发布，或者在最后，一切都完成了），然后他们会再次从默认分支合并回他们自己的分支。这确保了任何延迟的合并冲突都由该团队在其分支中处理，然后再将其发布给其他开发人员

当它们处理了由于该合并而产生的任何合并冲突时，它们可以从另一个方向合并，从分支返回默认值。此时，除非有人同时设法将任何冲突的更改合并/推送到默认值中，否则根本不会有合并冲突

这样做可以确保：

进行合并的开发人员接受合并方面的培训

进行更改的开发人员仍然保留着这些更改

您可以通过经常进行合并冲突，并将其分为小部分来分摊合并冲突所涉及的工作

当每个人都忘记了所有的改变，为什么要做这些改变，以及是谁做的时候，你不会在一个项目结束时得到一个大的合并——“一周”

如果有任何不清楚的地方，请留下评论，我会相应地更新/编辑