2

语境：

  • 7 位开发人员
  • 1 个产品
  • 3个分支：
    • 3.6 版（稳定版）
    • 3.7 版（稳定版）
    • 大师（开发）

制定的规则和政策：

  • 在早期版本中所做的任何修复都必须在所有未来版本中合并。
  • 集成是连续的：如果你在 3.6 中修复某些东西，你必须在推送之前在 3.7 和 master 中集成和测试。
  • 如果可能，请在提交之前重新调整您的工作，以便您两天前在本地提交的内容实际上会重新放在首位。我知道这是一个偏好问题，有利也有弊，但这是我们作为一个团队最喜欢的。

我们的问题：

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

正常集成工作：

  • Joe 和 Bill 致力于 3.6 中的两个不同的修复。
  • 乔完成了，他拉（和变基）
  • Joe 在他的 3.6 分支中最后一次测试
  • 乔切换到 3.7 并合并 3.6 -合并 1
  • Joe 再次测试，这次是在 3.7 的上下文中
  • 乔切换到 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收到的更改
  • 乔仍在 3.8 合并 3.7 -合并 7
  • 乔试图推动并祈祷在此期间没有人将某些东西推到 3.6。

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

4

1 回答 1

1

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

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

优点：

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

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

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

于 2013-10-02T22:37:11.247 回答