可以/应该避免频繁合并（例如通过变基）吗？

Question

我正在一个由5名开发人员组成的团队中开展一个更大的项目，我们将Mercurial用作VCS。

我们都倾向于在本地工作和提交，直到我们认为某个功能/修复程序已准备就绪，然后合并并推送我们的更改。我通常每天推几次（因而与远程合并），大多数其他人也是如此。

这通常会导致“合并混乱”：多个开发人员拉动，合并和推送变更集。由此产生的历史不是很漂亮，有时它看起来像这样：

我怀疑有人可以在这个混乱中隔离一个特定的变更集，或者甚至弄清楚它是如何/以什么方式影响的（至少我对前景感到不寒而栗）。

如果合并是必要的，我猜想上面的历史会很好，但是大多数这些合并都可以通过变基（安全）来避免，因为每个开发人员都在处理与其他任务相比更加孤立的特定任务。

实际问题：

• VCS历史如上所述是“正常”吗？这样的历史应该避免吗？
• 如何避免这样的历史？

关于“避免”部分：由于我们处理的任务有些孤立（Backend，Frontend，Web），我们可以将它们分成分支甚至是单独的存储库。虽然项目并不是完全独立的，所以我认为分成几个回购会导致更多的痛苦而不是获益。我不确定命名分支是否会好得多，因为那时我们经常有3个以上的分支，必须将它们合并到主干中。

重新映射似乎是一种选择，特别是因为许多变更集彼此完全独立 - 但是这会给决定是否对开发人员进行变基的负担。可能存在冲突，然后必须合并。这很可能导致人们首先没有变形，所以我们回到了现在的状态。

现在我想不出让历史看起来更清洁的另一种选择。它现在可能不是一个问题，但是当突然有20个开发人员会发生什么？如果历史是一个大迷宫，那么它有什么意义呢？如果有几十个交叉点，我认为很难跟踪变更集的影响。

Answer 1

当你让多个开发人员都在同一个存储库上工作时，你或多或少地看到了应该发生的事情。

唯一真正的解决方法是重写历史记录，特别是如果您已经进行了本地提交。你需要拉动，变形，然后推动。

编辑：你的修订图有一件事让我感到震惊。有一个很多来自分支机构并在这些子分支机构之间进行合并。它看起来很混乱。如果您的分支和合并与出现的一样混乱，那么他们或许您的团队可以从更加结构化的分支和合并方法中受益。

启发"Successful Git Branching Model"的git-flow也可以应用于Mercurial存储库。 hgflow是一个有助于实现它的扩展。

如果这看起来太多结构，那么你总能找到另一种前进方式。但是，值得投入一些想法并提请团队注意。

另请参阅：commit-pull-merge-push or pull-merge-commit-push?

Answer 2

是的，使用 rebase 并避免嘈杂合并其安全（因为hg-2.1）和简单< / strong>即可。

你是一个由5名开发人员组成的小团队。上面的所有合并最有可能发生是因为“我在部分X上做了一些提交，而不是Bob在部分Y上工作”。这些合并没有带来任何有用的信息，没有人关心独立使用微分支。

如果有一个良好的语义，在历史记录中保留分支是有用的，（例如：稳定的分支用于修复错误，默认分支用于新功能）或者更改需要很长时间才能成熟，并且值得与其他人合并。其他合并对我来说只是噪音。

自phases（Mercurial 2.1）引入以来，使用rebase 非常安全（默认情况下）Mercurial只允许您重新定义本地变更集。您的新工作流程可能如下所示：

• 克隆
• 劈
• 提交
• 劈
• 提交
• 拉
• 变基
• 测试
• 推

Answer 3

你正在寻找太多的抽象层次，然后抱怨它看起来太复杂了。可以选择将视图限制为分支的主线。用它。如果您有特定需求，只能深入研究合并的分支。最好让历史可用而且不需要用破坏它来破坏它。