version-control - 能否/应该避免频繁 merge (例如通过 rebase )？

Question

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

我们都倾向于在本地工作和提交，直到我们认为一个功能/修复准备好被推送，然后 merge 并推送我们的更改。我通常每天推送几次(并因此与远程 merge )，其他大多数人也是如此。

这通常会导致“merge 困惑”:多个开发人员拉取、 merge 和推送变更集。结果历史不是很漂亮，有时看起来像这样:

我怀疑人们能否从困惑中分离出一个特定的变更集，或者甚至弄清楚它是如何/以什么方式影响的(至少我对前景不寒而栗)。

如果 merge 是必要的，我猜上面的历史会很好，但是大多数这些 merge 可以通过 rebase 来(安全地)避免，因为每个开发人员都从事与其他任务或多或少隔离的特定任务。

实际问题:

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

关于“避免”部分:由于我们处理的任务有些孤立(后端、前端、Web)，我们可以将它们分成多个分支，甚至可能是单独的存储库。不过，这些项目并不是完全相互独立的，所以我认为分成几个 repo 协议(protocol)会带来更多的痛苦而不是收获。我不确定命名分支是否会好得多，从那时起我们经常有 3 个以上的分支，这些分支必须经常 merge 到主干中。

rebase 似乎是一种选择，尤其是因为许多变更集彼此完全独立——然而，这将决定是否 rebase 的负担推给了开发人员。可能会有冲突，然后最终必须 merge 。这很可能导致人们一开始就没有 rebase ，所以我们又回到了现在的状态。

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

Answer 1

您所看到的或多或少是当多个开发人员都在同一个存储库上工作时应该发生的情况。

绕过它的唯一真正方法是重写历史，特别是如果您已经进行了本地提交。您需要先拉动、 rebase ，然后再插入。

编辑:关于您的修订图表，有一件事让我印象深刻。有很多从分支分支和 merge 这些子分支。看起来，呃，困惑。如果您的分支和 merge 像看起来那样困惑，那么您的团队也许可以从更结构化的分支和 merge 方法中受益。

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

如果这看起来结构太多，那么您总能找到另一种前进方式。但是，可能值得投入一些思考并引起您的团队的注意。

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