Mercurial 推还是拉 背景：

我使用Mercurial作为一个单用户跟踪我对自己代码所做的更改，我认为我已经熟悉了基本原理。但是，我现在即将开始与实验室中的其他人一起进行软件项目，并希望确保我了解如何使用Mercurial与其他人正确地共享代码

我们的情况如下：我们都在Linux集群的共享卷中拥有自己的存储库（即不同的路径），并且我们都拥有对自己和彼此存储库的读写访问权限

为了便于讨论，我们可以称这两个存储库为：Bob和Alice的存储库

我的理解是，让Bob和Alice共享代码有多种方式，其中两种是：

选项1：通过拉动共享

• 每当鲍勃想看到艾丽丝的变化时，他总是拉着她
• 类似地，每当爱丽丝想看到鲍勃的变化时，她都会从他那里拉过来

选项2：通过推送共享

• 每当Bob想要与Alice共享他的更改时，他都会主动地将其更改推送到Alice的存储库中
• 同样，Alice在Bob想要与她共享其更改时，会主动将其更改推送到Bob的存储库中

问题： 通过阅读Mercurial文档和在线教程，我的理解是，通常首选上面的第一个选项，而不是第二个选项。我的一个问题是为什么

上述第二种选择会导致任何问题吗？如果Bob将提交到自己的存储库中，而Alice也同时将她的更改推到Bob的存储库中，会发生什么情况

---

从我读到的关于Hg文件模型的内容来看，它处理并发写操作非常优雅，所以文件损坏不是问题

问题更多的是关于工作流。不存在“同步”，因为稍后的写入操作将被阻止，直到较早的写入操作完成。如果Bob的提交更早，那么Alice的推送（默认情况下）将失败，因为它将创建一个新的头。她将不得不强制推动在Bob的回购协议中创建一个新的头，然后他将不得不合并它们。或者她可以拉鲍勃的零钱，合并，然后推。如果Alice的推送更早，那么Bob的提交将通过，创建一个他必须合并的分支。不管怎样，合并都必须发生。我不喜欢这种方法的一点是，Bob现在会对其回购协议中的这些新变更集感到惊讶，他将不得不进行hg更新，以将它们纳入他的工作副本中

---

我们在4人团队中使用的模式是，每个人都可以从中央回购中获取/推动。这也是我们的CI服务器运行自动化构建的地方。这已经顺利运行了11个月。

Mercurial可以轻松处理这两种情况。对我来说，选择一是首选，因为它更容易维护。如果Alice不希望Bob的变更被推到她的回购协议中怎么办？然后，她不得不经历一个艰难的过程，放弃他的努力。如果Alice想要拉Bob的更改，那么她显然已经同意拉取以及由此产生的合并，并且正在期待它。她很有可能会在与主要回购协议合并之前签订单独的回购协议，以确保她确实希望整合他的变化

也许只有我一个人，但把改变强加给别人感觉很肮脏。我更愿意让他们知道一个更新是可用的，如果他们感兴趣，他们可以从您那里获取更改

---

这就是说，我们在办公室处理它的方式是将大多数代码推送到每个人都可以访问的中央回购协议。在通过代码审查获得批准后，这些更改将被推到我们真正的回购协议中，供其他人使用。只有在极少数情况下，开发人员才会直接将代码推送到另一方，通常发生在他们密切合作于同一功能时。

要么起作用，最终它实际上并不重要，因为推/拉操作不会对收件人进行

更新

或

合并

——它只是将变更集移动到基础repo中，而不是移动到工作目录中

第一个选项，拉动，更常见，因为：

• 通常，您对彼此的回购协议没有写访问权限（可能也不应该），而通过拉取，您只需要对彼此的回购协议具有读访问权限
• 当您向某人推送变更集时，不会通知他们已收到新的变更集。他们只有运行

  hg summary

  （或

  hg heads

  或

  hg log

  ）才能发现它，然后他们必须

  hg merge

  。因此，只要收件人必须采取明确的操作（检查和合并）来获取您的更改，他们也可以只进行拉合并。这对他们来说不再是工作，对你来说也更少了

正如其他人指出的那样，在传入的推送或拉送操作期间，存储库写入外观将阻止提交