如何防止这么多合并（工作流程问题）

Question

上下文

• 7 devs
• 1个产品
• 3个分支：
  • 版本3.6（稳定）
  • 版本3.7（稳定）
  • Master（dev）

规则＆amp;政策到位：

• 必须在以后的所有版本中合并早期版本中的任何修补程序。
• 集成是连续的：如果您在3.6中修复了某些内容，则必须在推送之前在3.7和master中进行集成和测试。
• 如果可能的话，在你提交之前重新安排你的工作，这样你在两天前在当地投入的东西实际上会被重新放在首位。我知道这是一个偏好问题，有利有弊，但这是我们团队中最喜欢的。

我们的问题：

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

正常整合工作：

• Joe和Bill研究了3.6中的两个不同的修复。
• Joe完成了，他拉（和rebases）
• Joe在他的3.6分支中最后一次测试
• Joe切换到3.7并合并3.6 - 合并1
• Joe再次测试，这次是在3.7
的背景下
• Joe切换到3.8并合并3.7 - 合并2
• Joe再次测试，这次是在3.8
的背景下
• 乔准备推
• 比尔几乎做了同样的事情，但在乔拉开之后推了推。
• 乔试图推动，但操作失败，因为它会创建一个新头

痛苦（无用）合并：

• Joe拉，他从Bill，3.6,3.7和3.8
获得了东西
• Joe更新到3.6并合并他从拉动中获得的更改 - 合并3
• Joe更新到3.7并合并他从拉动中获得的更改 - 合并4
• Joe仍然在3.7合并3.6 - 合并5
• Joe更新到3.8并合并他从拉动中获得的更改 - 合并6
• Joe仍然在3.8合并3.7 - 合并7
• 乔试图推动并祈祷在此期间没有人将东西推到3.6。

我们正在考虑编写一个扩展（或批处理或程序）来自动合并这种情况。所以当Joe发现他无法推动时，他只会跑MergeUpAutomagically。但在我们尝试解决此问题之前，我想确保使用正确的工作流程。

Answer 1

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

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

优点：

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

• 更容易查看更改集的来源（来自哪个命名分支版本）。此外，如果有人误将较高版本推送到较旧版本，则很容易发现。

• 同步更具“原子性”。我们拉动并推送每个“官方”克隆命名分支，然后在“官方”命名分支之间拉（从较旧到较新）。 在你的情况下，也许Bill在Joe之前推出，但是他只有时间在3.6中完成它并且Joe意识到在同步到更高版本之前（不确定它会对你的情况有所帮助）。此外，也许没有必要像“发布”那样频繁地同步“dev”分支。