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

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

斯科特·查孔（Scott Chacon）去年在RailsConf的演讲非常精彩。这是我所见过的最有计划、最具信息性的谈话之一。我将听从他的建议（具体来说，对于您的问题，远程工作流部分大约在18分钟后开始）：

---

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

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

修订版“编号”本身不用于表示提交。显然，如果是这样的话，会有不止一个序列。。。在Git的情况下，唯一标识任何提交的指针“key”是SHA1散列。唯一使整个排列有序的是引用每个提交的父级的指针图

实际上，开发人员将其工作提交给自己的本地副本，当需要与他人共享时，他们会通过三种方式进行：

• 请其他开发人员直接从他们那里获取更改
• 直接推送到其他开发人员的副本中
• 将更改推送到其他人可以从中提取的中心位置

这些最终都是一样的，因为它只是合并了差异。在第三种场景中，中心位置仅充当代理——没有它也可以实现同样的效果

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

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

---

大多数合并都是自动发生的，但当发生冲突时，解决冲突通常是非常简单的。很好的一点是，你不会遇到一个跨越多个提交的冲突：它很容易解决，因为它在历史中间停顿，让你用更小的逻辑块来处理它。

不是用Sa1哈希来标识的吗？