并不是完全如此。分布式版本控制系统（DCVS）只是允许开发者在互相交流时不需要涉及到中央代码库，而官方代码库只是通过共识形成的“官方”。Linux也有一个中央代码库，从中创建了“官方”内核发布版本，但与集中式版本控制系统不同，中央“官方”代码库和客户端代码库之间没有实际上的物理区别。
1
您可能正在思考这样的图表：
相较于CVCS，这看起来可能会比较混乱。我听到你说：“我们需要一些秩序？"
如果没有中央代码库，想要找出最新更新版本的人、谁有大家都需要获取的功能x或错误修复y，似乎就很麻烦了。
是的，与CVCS不同，没有真正的“最新版本”。如果没有中央位置，您无法立刻知道最新版本是由Sue、Joe还是Eve提供的。中央位置有助于澄清最新的“稳定”版本。
可能更像这样：
值得注意的是，在组织内部，可能会有更多被认为是中央代码库的地方，这取决于人员组的职责。
想象一下管理多个开发团队的项目经理，每个团队可能有一个他们推送的“中心”代码库。每周，项目经理可能会从每个团队拉取更改到他的“中心”代码库中，合并它们并将它们重新推送到他的团队的“中心”代码库中。
这可能不是一个很好的例子（我仍在努力理解所有这些内容），但那只是一个项目经理。再加上几个项目/经理和QA团队，你也许就能知道我在说什么了。
--
- 图片和一段文字由Kalid Azad的一篇文章提供。
通过分布式源代码控制，中央“官方”存储库是根据政策建立的，而不是源代码控制工具的架构。
绝对不会违背Git的目的。
即使存在一个中央官方仓库，使用Git或任何其他分布式版本控制系统的优点仍然在于源代码控制是分散的。也就是说，你可以拿到仓库的副本，在你的代码上工作，并且每隔几分钟做一次本地提交。你不需要担心提交的是半成品代码，导致构建失败，这都是本地的。（而且非常快。）
然后当所有工作都完成时，你可以清理历史记录，并将完成的更改推送到中央仓库中，使其保持同质化和干净状态。
我认为你不能低估将“私有”提交和“公共”推送的想法分开的优点。即使只有你从这种小粒度中受益，也可以跟踪更改。
您可以强制任何希望
git push其开发的人首先进行git fetch + git merge，然后再推送。这并不完全打败Git的目的，并确保每个人都“同步”。
与Linus的“官方”存储库由JesperE提到的区别在于，它由不同的工作流程管理，即“独裁者和副手”模型，其中写入访问权限（推送）仅授予Linus，读取则授予任何人。
现在：“那是否违背了DVC的要点”？
不，您仍然拥有分布式存储库，每个开发人员一个，他们可以根据自己的内部团队工作流程在自己的存储库之间进行提取/合并。
但是，如果他们想要为中央存储库做出贡献，他们需要首先了解该存储库的最新历史记录。
2
我认为只要有点纪律，这个模型就非常有效。本文 很好地解释了您可以采用的各种模型。
像Git这样的分布式版本控制系统并不强制使用中央仓库。当然，可以将一个仓库声明为“中央”、“官方”或其他名称，在公司环境中，中央仓库在某种程度上是有意义的——如果不是用于开发，至少也是用于备份目的。
3
原文链接