我正在一个由 5 名开发人员组成的团队中开展一个更大的项目，我们使用 Mercurial 作为 VCS。
我们都倾向于在本地工作和提交，直到我们认为可以推送一个功能/修复，然后合并并推送我们的更改。我通常每天推送（并因此与远程合并）几次，其他大多数人也是如此。
这通常会导致“合并混乱”：多个开发人员拉取、合并和推送变更集。生成的历史不是很漂亮，有时看起来像这样：
我怀疑人们是否可以在混乱中分离出特定的变更集，或者甚至弄清楚它是如何/以何种方式影响的（至少我对前景感到不寒而栗）。
如果合并是必要的，我想上面的历史会很好，但是大多数这些合并可以通过重新定位（安全地）避免，因为每个开发人员都在处理与其他任务或多或少隔离的特定任务。
实际问题：
- VCS 历史看起来像上面这样“正常”吗？应该避免这样的历史吗？
- 如何避免这样的历史？
关于“避免”部分：由于我们处理的任务有些孤立（后端、前端、Web），我们可以将它们拆分为分支，甚至可能是单独的存储库。不过，这些项目并不是完全独立的，所以我认为分成几个 repos 会带来更多的痛苦而不是收获。我不确定命名分支是否会更好，因为从那时起我们经常在那里有 3 个以上的分支，这些分支必须经常合并到主干中。
变基似乎是一种选择，特别是因为许多变更集彼此完全独立——但这将决定是否变基的负担交给开发人员。可能会有冲突，然后一个人毕竟必须合并。这很可能会导致人们一开始就没有变基，所以我们又回到了现在的状态。
现在我想不出另一种让历史看起来更干净的选择。现在可能不是什么大问题，但是当突然有 20 个开发人员时会发生什么？如果历史是一个大迷宫，那它的意义何在？如果有几十个交叉点，我认为很难跟踪变更集的影响。