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

Question

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

Answer 1

去年RailsConf的Scott Chacon的演讲非常棒。我见过的最好的计划和信息谈话之一。我会推荐他（特别是，对于你的问题，远程工作流程部分大约18分钟开始）：

RailsConf Git Talk

Answer 2

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

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

修订版“数字”本身并不用于指代提交。显然，如果是这样的话会有不止一个序列......在Git的情况下，唯一标识任何提交的指针“key”是SHA1哈希。使整个排列顺序的唯一因素是引用每个提交的父级的指针图。

在实践中，开发人员将他们的工作提交给他们自己的本地副本，当他们与其他人共享时，他们会以三种方式这样做：

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

这些实际上是完全相同的，因为它归结为合并差异。在第三种情况下，中心位置仅仅作为代理 - 没有它就可以实现同样的目标。

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

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

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