将多个Mercurial分支合并在一起

Question

我有一群开发人员使用分支机构修复错误。我的需求：自动化（或有办法）将所有这些分支合并到一个主分支中的最佳方法是什么，“默认”。

由于

Answer 1

注意：这是我的意见，这里可以有多个意见，但至少在此理解我的观点，并决定你想要它与众不同。

首先，这里缺少一些东西，我想从长远来看这会给你带来工作流问题。

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

无论如何，完全自动化，这是行不通的。

这是开发人员应该使用的工作流程（在我看来。）

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

这有三个主要好处：

1. 他们总是在他们自己的分支中拥有最新的代码，并且不会陷入解决已经在另一个分支中修复的已知错误
2. 他们不断处理来自其他分支机构的合并冲突，而冲突很小，而且这些变化在开发人员的脑海中仍然是新鲜的。
3. 由于你每天处理合并冲突（如果有的话），当你到达那个分支的生命周期时，它几乎完全与默认分支合并，所以合并它所涉及的工作如果不是免费的，现在回到默认应该是便宜的。

在某些时候，他们被阅读以将他们的工作重新集成到默认分支中（或者是周期性的，即新功能的部分发布，或者最后，一切都已完成），然后他们又做了另一次合并从默认回到自己的分支。这可确保任何延迟合并冲突由该团队在其分支中处理，然后再将其发布给其他开发人员。

当他们处理由于该合并引起的任何合并冲突时，他们可以合并另一个方向，从其分支返回到默认。此时，除非有人在此期间设法将任何冲突的更改合并/推送到默认值，否则根本不存在合并冲突。

这样做可以确保：

1. 进行合并的开发人员可以进行合并培训
2. 进行更改的开发人员仍然记忆中的这些更改
3. 通过经常进行合并冲突来分摊合并冲突所涉及的工作，并将其分成小部分。
4. 在项目结束时，你没有得到一个大的合并 - “周”，当时每个人都忘记了所有的变化，他们为什么要完成以及是谁做了这些变化

如果其中任何一项不清楚，请发表评论，我会相应地更新/编辑。