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

Question

我想知道去中心化的DVCS是如何工作的？如果没有中央服务器，开发人员机器如何知道存储库并将其与其他开发人员机器的存储库同步。这些更改是如何合并的？因为在我看来缺少中央服务器，系统可能会导致每个存储库都有不同的修订号。如何处理冲突解决方案？

Answer 1

我偏向于Git，但我相信这个理论适用于大多数其他系统……

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

修订版的“数字”并不是用来指提交的。显然，如果是这样的话，将会有不止一个序列...在Git的情况下，唯一标识任何提交的指针“键”是一个SHA1散列。唯一使整个安排顺序化的是引用每个提交的父对象的指针图。

在实践中，开发人员将他们的工作提交到自己的本地副本，当需要与他人共享时，他们通过三种方式完成：

• 要求其他开发人员直接从中提取更改
• Push直接推送到其他开发人员的copy
• 将更改推送到其他开发人员可以从

中提取的中心位置

最终，这些都是相同的事情，因为它只是归结为合并差异。在第三个场景中，中心位置仅充当代理--没有它也可以实现相同的功能。

系统可以是集中式的，也可以是分散式的，这取决于您的选择。由于实际原因，大多数项目都有一定程度的集中化，但在任何时候，fork都可以成为新的中央存储库，或者开发人员可以选择在自己之间临时交换代码。

当提交被获取并合并到您自己的副本中时，这些将应用于您与上游存储库共享的任何公共祖先之上。如果存在冲突，合并过程将在发生冲突的提交步骤处暂停，并要求您在继续在其上应用其余提交之前解决该冲突。(使用标准的统一差异标记来标记冲突。)

大多数合并都是自动发生的，但当出现冲突时，解决起来往往相当简单。好的是，你不会因为几次提交而结束一团冲突:这更容易解决，因为它在历史中间暂停，让你以更小的逻辑块来处理它。

Answer 2

Scott Chacon去年在RailsConf上的演讲非常棒。这是我见过的最好的计划和信息的演讲之一。我将听从他的意见(具体来说，对于您的问题，远程工作流部分大约在18分钟后开始)：

RailsConf Git Talk