大型水银储存库是否遭受“推动种族”的困扰？

阅读一些“为什么DVCS更好”回答了有关Programmers.SE的几个问题。他们似乎都说，总的来说，DVCS更好，因为您没有大型项目中的提交竞赛，即IE提交，已经过时了，所以更新，提交，再次过时，提交，仍然过时等。

DVCS通过推送的概念限制了这一点。但是，在大型项目中，会不会有一场“推动竞赛”，尤其是在一天结束时？我知道在Git中这可以通过对所有事物的不断分支来弥补，但是在Mercurial中，您不需要分支，而是创建一个新的头部。

我看到的问题

1. 用户尝试推送
2. 过时（如果本地存储库过时，Mercurial不会让您推送），因此您可以拉并合并本地更改
3. 用户尝试再次推送，但是当他们合并其他推送时，他们又过时了
4. 再次拉并合并
5. 仍然过时
6. 重复

听起来有点熟？

这是非常大且受欢迎的水银回购的实际问题吗？当每个人都在最后一天努力工作时，在公司内部怎么办？

据我所知，大多数使用DVCS的大型开源项目都使用“拉请求”而不是推，即用户请求项目从其分支中拉出，并且项目可以选择以任何顺序进行这些拉出请求，如果有的话。正如您所命名的，这消除了对“推动比赛”的需求。

在其他公司，我无法保证流程，但是在我工作的地方这不是问题。

看，当您处理案件时，您正在处理整个仓库的分支，因此您的推送请求将转到主干的远程版本。当您要将（完成的）更改集成到主干中时，可以加载主干，拉出，合并，推送。

偶尔（非常偶尔）会有两个人尝试同时执行此操作（通常是由于沟通不畅造成的）。在这种情况下，“丢失”的人将只需要重新拉，合并，推动即可。由于没有下午5点急于提交到中央存储库的问题，因此您所概述的问题并不存在。

这就是DVCS的优点：分支无痛，因此每个人都可以在自己的分支上工作。

编辑

哦，我只是注意到您的“自然而然地，您不会分支……”评论：是的，您做到了。您不必这样做，但是由于这样做非常容易，并且这样做的好处远大于不这样做的好处，因此您确实会倾向于只使用分支存储库。

不，没有推动竞赛，因为工作是在主题分支中完成的。合并母版管理将分支合并为集成分支的（相对较低）的复杂性。通常这是连续进行的。有关分布式版本控制工作流的更多信息，第一个来源是马的嘴：man gitworkflows，在线此处。尽管您的主张和技术类似，但Mercurial工作流确实使用分支。