作为Subversion的前用户，我们决定转移到Mercurial for SCM，这让我们感到困惑。虽然Mercurial是一个分布式的SCM工具，我们使用的是远程回购，以保持我们做备份的服务器上进行更改，但我们发现一些暂时困难。
例如，当两个或三个人在我们的本地仓库的工作，我们承诺然后推送到远程的回购中，我们发现了很多的头（？）创建。这混淆了我们的地狱，我们不得不做一些合并等来解决它。
避免这么多脑袋并让远程回购与众多开发者保持同步的最佳方法是什么？
今天，我一直在这样工作：
这是最好的进展吗？
虽然今天这种方法运作良好，但我不禁感到我做错了！说实话，我不明白为什么合并甚至需要，因为其他人都在不同的文件工作将在拉阶段做了什么？
除了告诉我RTFM你有任何使用Mercurial的提示是这样的吗？有什么好的在线资源可以获得有关我们为何如此多的人的信息？
注：我看了手册，但它并没有真正提供多少细节，我不认为我要开始另一本书在一分钟的
答案 0 :(得分：11)
你一定要找到一些学习资源。
我可以推荐以下内容：
至于你的具体问题，“这是最好的程序”，那么我就不得不说。
以下是一些提示。
首先，您无需始终与中央存储库保持“同步”。相反，请遵循以下准则：
换句话说，这是典型的一天。
当你早上进来时，你会提取最新的更改，以便获得最新的本地克隆。如果你正处于昨天没有完成的更大变化的中间，你可能并不总是这样做。
然后你就开始工作了。您提交了具有独立更改的小变更集这并不是说您将更大的错误修正分成许多较小的提交只是因为您修改了多个文件，但是尝试避免一次修复多个错误，或者实现多个功能一次。尽量保持专注。
然后，当您对本地添加的所有变更集感到满意时，您决定推送到服务器。当您尝试执行此操作时，会收到一条中止消息，指出额外的磁头将被推送到服务器，这是不允许的，因此推送被中止。
相反，你拉。这总是可以完成，但是当然现在会在本地克隆中添加额外的头，而不是在服务器上。然后，您将从服务器获得的额外头部与您自己的头部合并，即您在白天通过向克隆提交新的更改集而创建的头部。您可以解决任何合并冲突。
然后你推，现在它应该成功。如果有人在您忙着合并时设法将更多变更集推送到中央存储库，那么您将获得另一次中止并且必须冲洗并重复。
历史记录现在将显示多个并行的开发分支，但应始终保持在中央存储库中最多1个头。如果，稍后，您开始使用命名分支，则每个命名分支可以有1个头，但是在您获得默认分支的挂起之前，请尽量避免这种情况。
至于你为何需要合并？好吧，Mercurial总是使用作为整个项目快照的修订，这意味着两个分支，即使它们包含对不同文件的更改，实际上被认为是整个项目的两个不同版本，你需要告诉Mercurial它应该结合起来他们回到一个版本。
答案 1 :(得分：4)
首先，你可以随时拉; pull只是将更改集添加到您的仓库，但不会更改您的本地工作文件（除非您已经启用了post-pull更新）。
如果其他人已将更改提交到您当前正在处理的同一分支，则必须进行合并。这创建了一个隐式分支，合并只是将它们重新组合在一起。您可以通过存储库视图中的“铁路轨道”很好地看到这一点。基本上，只要您不合并，就可以保留在自己的“私有”轨道上，当您想要添加更改（可以是任意数量的更改集）时，将其合并回目标分支（通常为“默认”） ）。它没有任何意义 - 就像在较旧的SVN版本中合并一样！
因此，工作流程并不像您显示的那样严格;它更像是这样：
可以稍微调整此工作流程，例如使用命名分支，有时使用rebase。但是，您和您的团队应决定要使用的工作流程; Mercurial在这方面非常灵活。
答案 2 :(得分：2)
http://hginit.com有一个很好的教程。
特别是，您可以在此处找到您的步骤列表：http://hginit.com/02.html（位于页面底部）
这些步骤与您的步骤之间的区别在于您应该在步骤1之后提交。事实上，在进入pull / merge / push步骤之前，您通常会在本地存储库上多次提交。您不需要立即与其他开发人员共享每个提交。做一些相关的改变然后推动整个事情通常是有意义的。