我想知道分散的 DVCS 是如何工作的?如果没有中央服务器,开发人员机器如何知道存储库并将其与其他开发人员机器的存储库同步。以及如何合并更改?因为在我看来缺少中央服务器,系统可能会导致每个存储库都有不同的修订号。以及如何处理冲突解决方案?
2 回答
Scott Chacon 去年在 RailsConf 的演讲非常棒。我见过的最好的计划和信息会谈之一。我会听他的(具体来说,对于您的问题,远程工作流程部分大约在 18 分钟后开始):
我偏爱 Git,但我相信该理论适用于大多数其他系统......
分散式 VCS 旨在通过在每次提交中保留指向先前提交的指针来处理分支和合并作为其 DNA 的一部分,因此任何更改都可以追溯到共同的祖先。
修订版“数字”本身不用于指代提交。显然,如果是这种情况,将会有不止一个序列......在 Git 的情况下,唯一标识任何提交的指针“key”是一个 SHA1 哈希。使整个排列顺序的唯一因素是引用每个提交的父级的指针图。
在实践中,开发人员将他们的工作提交到他们自己的本地副本中,当需要与他人共享时,他们会通过以下三种方式进行:
- 要求其他开发人员直接从他们那里提取更改
- 直接推入其他开发者的副本
- 将更改推送到其他人可以从中提取的中心位置
归根结底,这些实际上是一回事,因为它归结为合并差异。在第三种情况下,中心位置仅充当代理——没有它也可以实现同样的事情。
该系统可以是您选择的集中式或分散式。出于实际原因,大多数项目都有一定程度的集中化,但在任何时候,一个分支都可以成为新的中央存储库,或者开发人员可以选择在他们自己之间临时交换代码。
当提交被提取并合并到您自己的副本中时,它们将应用于您与上游存储库共享的任何共同祖先之上。如果存在冲突,则合并过程会在发生冲突的提交步骤处暂停,并要求您在继续应用其余提交之前解决它。(标准的统一差异标记用于标记冲突。)
大多数合并是自动发生的,但是当发生冲突时,解决起来通常很简单。好消息是您最终不会遇到跨越多个提交的大量冲突:它更容易解决,因为它会在历史中间暂停并让您以更小的逻辑块来处理它。