Mercurial 如何防止如此多的合并（工作流问题） 背景： 7开发人员 1产品 3个分支机构： 3.6版（稳定版） 3.7版（稳定版） 硕士（发展） 制定的规则和政策： 在早期版本中进行的任何修复都必须合并到所有未来版本中 集成是连续的：如果您修复了3.6中的某些内容，则必须在3.7和master中进行集成和测试，然后才能继续 如果可能的话，在你提交之前对你的工作进行重新定基，这样你两天前在本地提交的东西实际上会重新放在首位。我知道这是一个偏好的问题，有利弊，但这是我们作为一个团队最喜欢的 我们的问题是：

我们有太多无用的合并操作要做。下面是一个场景：

正常集成工作：

• Joe和Bill在3.6中进行了两个不同的修复
• 乔完成了，他拉（和再扣）
• 乔最后一次在他的3.6分支中进行测试
• Joe切换到3.7并合并3.6-合并1
• Joe再次测试，这次是在3.7的上下文中
• Joe切换到3.8并合并3.7-合并2
• Joe再次测试，这次是在3.8的上下文中
• 乔准备推
• 比尔做了几乎相同的事情，但乔一拉，比尔就推开了
• 乔试图推动，但操作失败，因为这将创建一个新的头部

痛苦（无用）合并：

• 乔拉，他在3.6，3.7和3.8中从比尔那里得到了东西
• Joe更新到3.6并合并从pull-merge 3收到的更改
• Joe更新到3.7并合并从pull-merge 4收到的更改
• 乔仍然在3.7合并3.6-合并5
• Joe更新到3.8并合并从pull-merge 6收到的更改
• Joe仍然在3.8合并3.7-合并7
• 乔试着推，祈祷没有人同时推到3.6

---

我们正在考虑编写一个扩展（或批处理或程序）来自动合并这种情况。因此，当乔发现他无法推动时，他会自动运行

mergeupautomatically

。但在我们尝试修复此问题之前，我想确保我们使用了正确的工作流。

如果我理解，您正在同一克隆中使用命名分支

我发现为每个版本（版本、开发人员）使用不同的克隆更容易，其中每个克隆都包含与该版本相关的命名分支（以及来自较旧分支的变更集）。我们有“官方”克隆，我们在那里同步（拉和推）

优点：

• 不需要通过执行hg更新来“切换”（在我的情况下，我使用Eclipse实例，每个项目有不同的工作空间）。我曾经在同一个克隆中使用命名分支，但发现它令人困惑

• 更容易看到变更集的来源（命名分支版本）。此外，如果有人错误地从一个更高的版本推到一个更旧的版本，很容易被发现

• 同步更“原子化”。我们为每个名为分支的“官方”克隆拉和推，然后在名为分支的“官方”克隆之间拉（从旧分支到新分支）。 在您的情况下，可能是Bill先于Joe，但在3.6中只有时间这么做，而Joe在同步到更高版本之前就意识到了这一点（不确定这对您的情况是否有帮助）。此外，可能不需要像同步“发布”一样频繁地同步“dev”分支

---

我认为这更适合程序员。stackexchange.com。您的问题似乎是推送间隔时间太长。另外，

mergeupautomatically

是否意味着将未测试的代码推送到一个稳定的分支？如果添加测试，额外的合并不再无用：-）否，

mergeupautomatically

将不用于执行正常的集成工作，仅在第一次推送操作失败时重新合并。如果没有合并冲突，程序将合并并继续，这在大多数情况下都会发生。在合并冲突的情况下，程序将中止并报告一个错误，表明有必要进行有意义的（手动）合并。由于您在3.7和3.8中进行了Joe测试，无论他是否有冲突，我猜您担心合并会引入（“无声”）问题。您仍然倾向于自动运行MergeUp，但是Bill的更改可能会在Joe的代码中引入错误，而不会产生冲突，就像Joe的代码可以在不冲突的情况下破坏Master一样。对于我的团队，我们不会在3.7/3.8/Master中测试Joe的代码，除非合并特别复杂。相反，我们坚持总是为新代码编写单元测试，并依靠这些测试来捕获合并带来的问题。虽然，不可否认，我们发现合并问题的机会直接取决于单元测试覆盖的范围。事实上，我们确实在PC上本地使用每个分支的一个克隆，但只有一个中央存储库。这不会改变我的场景中合并操作的数量。如果您将“Joe updates to…”替换为“Joe changes his directory to…”则会得到相同的最终结果。关于第三点，我们不希望这样做，因为如果Joe在3.6中推动并计划在3.7中拉这些提交以进行集成，然后，当另一个开发人员想要从3.6中合并他自己的工作，并且不情愿地提取Joe的未整合提交时，他可能会被迫执行该集成工作。这会产生较少的合并操作，但会造成一个开发人员必须集成到另一个开发人员的工作中的情况。