分布式修订控制系统的分散行为如何工作？

Question

我想知道分散式DVCS的工作如何？如果没有中央服务器，开发人员机器如何知道和同步存储库与其他开发人员机器的存储库。这些更改如何合并？因为缺乏中央服务器似乎对我来说系统可能会导致每个存储库有不同的版本号。以及如何处理冲突解决方案？

Answer 1

我偏爱的Git，但我相信理论适用于大多数其他系统...

分散式VCS旨在通过在每次提交中保留一个指向先前提交的指针来处理分支和合并作为其DNA的一部分，因此任何更改都可以追溯到共同的祖先。

版本“数字”本身不用于引用提交。显然，如果是这种情况，将会有多个序列...在Git的情况下，唯一标识任何提交的指针“key”是SHA1哈希。使整个安排顺序唯一的是指向每个提交的父代的指针图。

在实践中，开发者提交他们的工作，以自己的本地副本中，当它的时间与他人分享，他们在三个方面这样做：

• 向其他开发者直接拉动变化从他们
• 直接推到其他开发人员的副本
• 变更推到中央位置，其他人可以从

拉这些都是真正在T同样的事情他结束了，因为它只是归结为差异。在第三种情况下，中央位置仅仅作为代理 - 没有它，同样的事情就可以实现。

系统可以像您选择的那样集中或分散。由于实际原因，大多数项目都具有一定数量的集中化，但任何时候叉都可以成为新的中央存储库，或者开发人员可以选择自己之间交易代码。

当提交被提取并合并到您自己的副本中时，它们将应用于您与上游存储库共享的任何共同祖先之上。如果发生冲突，合并进程将在发生冲突的提交步骤处暂停，并要求您在继续将其余提交应用于其上之前解决该问题。 （标准的统一差异标记用于标记冲突。）

大多数合并是自动发生的，但是当发生冲突时，通常很难解决。好处是，最终不会出现跨越多个提交的冲突的球：它更容易解决，因为它在历史中间暂停，并允许您以更小，逻辑的块处理它。

Answer 2

去年Scott Chacon从RailsConf的介绍非常棒。这是我见过的最好的计划外信息会谈之一。我会听从他（具体而言，你的问题，远程工作流程的一部分围绕18分钟开始到它）：

RailsConf Git Talk