是否使用中央存储库违背GIT的目的？
如果你的企业环境中有很多人在某个特定的应用程序上工作，那么这个分布式版本控制系统是否有官方的中央存储库呢？
有时候，我很难理解分布式版本控制系统的概念，比如企业环境中的GIT 。 如果您没有中央存储库，那么是不是PITA来确定谁拥有最新的更新版本，谁拥有需要抓取的特性或错误修复function等等。
它是否击败了GIT的目的，以类似于SVN的方式使用它，每个人都推送一个中央存储库？ 每当我想到做到这一点，我就觉得我错过了一切。
有人能教导我吗？
不是真的。 DCVS只是允许更多的自由，如何在不涉及中央存储库的开发人员之间进行交互。 官方存储库只能以协商一致方式正式存放 Linux也有一个中央存储库，“官方”内核版本是从这个存储库创build的，但是中央“官方”版本库和客户端版本库在集中式VCS中没有实际的区别。
你可能正在按照这个图的方向思考：
这可能看起来像来自CVCS的混乱。 “我们需要一些命令”，我听到你说呢？
如果您没有中央存储库，那么是不是PITA来确定谁拥有最新的更新版本，谁拥有需要抓取的特性或错误修复function等等。
是。 与CVCS不同的是，它并没有真正的“最新版本”。 如果没有中心位置，你不会立即知道是否看到苏，乔或夏娃的最新版本。 中央位置有助于澄清最新的“稳定”版本是什么。
更像这样的东西：
也可能值得注意的是，根据组织内部人员的职责范围，可能有不止一个中央知识库。
设想一个pipe理多个开发团队的项目经理，每个团队都可能有一个“中央”的存储库，他们会推动。 每个星期，项目经理可能会把每个团队的变化都放到他的“中央”仓库，合并它们并把他们推回到他们团队的“中央”仓库。
这可能不是一个很好的例子（我仍然对这个问题感到头疼），但那只是一个项目经理。 再投入几个项目/经理和QA团队，那么你可能会看到我来自哪里。
–
- 图和一段Kalid Azad的一篇文章的礼貌
通过分布式源代码控制，中央“官方”存储库由策略而不是源代码控制工具架构来build立。
绝对不会打败Git的目的。
使用Git或任何其他DVCS的好处，即使有一个中央的，官方的存储库仍然是源控制分散。 也就是说，你可以把你的版本库，处理你的代码，每隔几分钟做一次本地提交，如果你需要的话。 您不必担心提交是在完成的代码中完成的，它都是本地的。 （而且速度非常快）
然后，当所有工作完成后，您可以清理历史logging，并将已完成的更改推送到中央存储库，使其处于同质，清洁的状态。
我不认为你可以低估把“私人”承诺和“公共”推动分开的好处。 它允许跟踪变化，即使你是唯一一个从这样小的粒度中受益的人。
如果你检查这个Git演示文稿 （幻灯片475及以下），Git完全支持中央存储库模型。
你可以强迫任何人git push它的开发，首先做一个git fetch + git merge ，然后推。
这完全不能击败Git的目的，并确保每个人都彼此“同步”。
与Jesper提到的Linus的“官方”存储库的不同之处在于，它是由不同的工作stream程pipe理的，即“独裁者和中尉”模式，其中写入访问（推送）仅授予Linus，读取授予任何人。
现在：“这是否击败了DVC”？
不，您仍然拥有分布式存储库，每个开发者都有一个存储库，他们可以根据自己的内部团队工作stream程在自己的存储库之间取出/合并。
但是，如果他们想要为中央仓库做出贡献，他们需要首先了解仓库的最新历史。
DVCS的主要优点之一是可以从“官方”仓库获取最新版本，然后冒险。 您可以在本地提交更改并随意回滚。 这也意味着你甚至可以在没有访问中央存储库的情况下工作，并且仍然具有源代码控制的好处。
我觉得这个模型运作得很好。 这篇文章解释了你可以采用的各种模型
像Git这样的DVCS不会强制您使用中央存储库。 当然，可以声明一个存储库是“中央”的，也可以是“官方”的，或者在公司的情况下，中央存储库是有一定意义的，如果不是为了开发，至less为了备份目的。
