合并多个Mercurial分支

Question

我有一批开发人员使用分支来修复错误。我的需求是：自动合并所有这些分支到一个主分支“default”的最佳方法是什么（或者是否有一种方法）。

谢谢。

- KingFish

Answer 1

注意：这是我的看法，可能有多种不同的看法，请至少理解我的观点并决定是否做出不同的选择。

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

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

无论如何，完全自动化地执行这个任务是不可行的。

以下是开发者应使用的工作流程（在我看来）。

定期地，例如每天早上，分支上的开发者应检查构建服务器以确保默认分支正在构建。如果它构建成功（也应该！），他们从默认分支向下合并到自己的分支。

这有三个主要好处：

1. 他们在自己的分支中始终拥有最新的代码，并且不会因为已经在其他分支中修复的已知错误而陷入困境。 2. 他们不断处理来自其他分支的合并冲突，同时冲突很小，且更改对于做出这些更改的开发者来说仍然很新鲜。 3. 由于您每天都要处理合并冲突（如果有），因此当您到达该分支的生命周期结束时，它已经几乎完全与默认分支合并了，因此将其合并回默认分支所需的工作现在应该很便宜，如果不是免费。

在某个时候，他们准备将自己的工作集成回默认分支（无论是定期地，即部分发布新功能，还是在最后，一切都完成了），然后他们又从默认分支向下进行了另一次合并。这确保了任何悬而未决的合并冲突都由该团队在他们的分支中处理，然后再将其发布给其他开发者。

当他们处理完由于该合并而产生的任何合并冲突时，他们可以将其合并回到默认分支。此时，除非有人设法在此期间将任何冲突的更改合并/推送到默认分支，否则根本不会存在任何合并冲突。

这样做可以确保：

1. 执行合并操作的开发人员接受合并培训 2. 进行更改的开发人员仍然记得这些更改 3. 您通过经常执行它们并将它们分成小部分来分摊涉及合并冲突的工作量。 4. 在项目结束时，当每个人都忘记了所有更改，为什么要进行这些更改以及谁进行了这些更改时，您不会遇到一周大的合并。

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

- Lasse V. Karlsen