对于大型团队，不得不拉/更新/合并然后每次提交都没有意义，特别是当其他开发人员更改的文件与我的变更集文件无关时。
即。我更改了file1.txt，而其他人更改了file10.txt。为什么我必须在允许推送之前合并到我的计算机上？
会让人感到很痛苦，因为如果许多开发人员都在提交，你必须经常拉/更新/合并。
此外，它使您的变更集看起来比它更大，因为它将合并显示为单独的提交。
答案 0 :(得分：9)
Mercurial让你这样做，因为它的原子单元不是一个文件而是一个变更集。这是一个包含一组更改的节点。每个变更集都是历史记录中的单个节点，代表该人员所做的事情。即使没有更改的公共文件（这将是一个简单的自动合并），这也会导致您必须合并。这些合并节点非常重要，因为它们是您的存储库历史记录的一部分，并为Mercurial提供了更多信息，以便将来与祖先信息进行合并。
这就是说你可以使用一个扩展程序来清理你的历史记录（但是在你推动之前不需要拉动你就不会解决你的问题）。它被称为rebase extension，它随Mercurial一起提供，但默认情况下已禁用。它为pull添加了一个新的文档，如下所示：
hg pull --rebase
这将提取新的更改并将本地变更集线性地移动到它们之上而不具有合并变量集。但是，我会强烈反对使用它，因为您重写其历史记录后确实会丢失有关您的存储库的信息。请阅读this post，了解可能导致的一些问题。
答案 1 :(得分：5)
好吧，您可以尝试使用rebase，这将避免合并提交，但它并非没有自己的危险。你也可以通过做“hg pull --update”而不是单独的hg pull来崩溃到一步; hg update命令。
至于为什么必须在计算机上合并：这是mercurial作为分布式版本控制系统的直接后果。没有可以被认为是规范的中央服务器（除非您按照惯例创建一个），因此没有其他“地方”可以进行合并。您是唯一可以决定如何将您的仓库中的信息与远程仓库中的信息相结合的人。必须记录这些决策的结果，这是合并提交的起源。
此外，在您的示例中，合并将在没有用户交互的情况下发生，因为没有冲突（对于rebase也是如此），所以我不明白为什么这是一个问题。
答案 2 :(得分：2)
因为在分离文件中进行更改并不能保证它们是独立的。
当您提交更改时，即使它们位于本地更改未触及的文件中，也可能导致本地更改停止工作。例如。您可以更改从新编写的代码访问的接口。
这就是为什么中间始终存在合并步骤，以便人们可以在将更改集成回主存储库之前查看更改，测试问题并解决它们。这一步非常重要，因为跳过它可能会阻止所有这50-100名同事（非常昂贵）。
我会接受拉斯的建议并且不那么频繁地推动。如果你只需要每天做两次或三次，那么合并并不是什么大问题。也可以创建较小的团队存储库（或分支），每天由指定人员与主存储库合并。