33

如果您在一个公司环境中，有很多人在开发一个特定的应用程序，那么拥有一个官方的中央存储库是否违背了分布式版本控制系统的原则？

有时我很难理解公司环境中分布式版本控制系统（如GIT ）的概念。如果您没有中央存储库，那么是否需要 PITA 才能确定谁拥有最新的更新版本，谁拥有每个人都需要获取的功能 x 或错误修复 y，等等等等。

以与SVN类似的方式使用它是否违背了GIT的目的，它有一个每个人都可以从中推/拉的中央存储库？每次我想到这样做时，我都觉得我错过了所有事情的重点。

有人可以启发我吗？

4

7 回答 7

29

并不真地。DCVS 只是允许在不涉及中央存储库的情况下如何在开发人员之间进行交互方面更自由。官方存储库仅是官方共识。Linux 也有一个中央存储库，从中创建“官方”内核版本，但中央、“官方”、存储库和客户端存储库之间没有物理区别，因为它在集中式 VCS 中。

于 2009-01-20T08:55:16.310 回答
29

您可能正在按照此图的思路思考：

替代文字

这可能看起来像是来自 CVCS 的混乱。“我们需要一些命令”，我听到你说？

如果您没有中央存储库，那么是否需要 PITA 才能确定谁拥有最新的更新版本，谁拥有每个人都需要获取的功能 x 或错误修复 y，等等等等。

是的。与 CVCS 不同 没有真正的“最新版本”。如果没有中心位置，您不会立即知道是否要查看 Sue、Joe 或 Eve 的最新版本。中心位置有助于阐明最新的“稳定”版本是什么。

有点像这样：

替代文字

还可能值得注意的是，根据组织内人群的职权范围，可能存在多个感知的中央存储库。

想象一个管理多个开发团队的项目经理，每个团队可能有一个他们推送到的“中央”存储库。每周，项目经理可能会将每个团队的更改拉入他的“中央”存储库，合并它们并将它们推送回他的团队的“中央”存储库。

这可能不是一个很好的例子（我仍然在思考这一切），但这只是一个项目经理。再加入几个项目/经理和 QA 团队，然后你可能会看到我来自哪里..

--

于 2009-01-20T10:43:30.100 回答
8

使用分布式源代码控制，通过策略而不是源代码控制工具架构建立一个中央“官方”存储库。

于 2009-01-20T08:58:27.037 回答
6

绝对不会违背 Git 的目的。

即使有一个中央的官方存储库，使用 Git 或任何其他 DVCS 的优势仍然是源代码控制是分散的。也就是说，您可以获取存储库的副本，处理您的代码，并在需要时每隔几分钟进行一次本地提交。您不必担心提交是在破坏构建的半完成代码上，它都是本地的。（而且非常快。）

然后，当所有工作完成后，您可以清理历史并将完成的更改以同质、干净的状态推送到中央存储库。

我认为你不能低估将“私人”提交和“公共”推送分开的优势。即使您是唯一受益于如此小粒度的人，它也允许跟踪更改。

于 2009-01-20T10:08:41.963 回答
4

如果您查看此Git 演示文稿（幻灯片 475 及以下），Git 完全支持中央存储库模型。

您可以强迫任何希望git push其发展的人先做出git fetch + git merge第一个，然后再推动。

这根本不会违背 Git 的目的，并确保每个人都彼此“同步”。

JesperE 提到的 Linus 的“官方”存储库的不同之处在于它由不同的工作流程管理，即“独裁者和副手”模型，其中写入访问（推送）仅授予 Linus，而读取授予任何人。

现在：“这是否违背了 DVC 的观点”？

不，您仍然有分布式存储库，每个开发人员一个，他们可以根据自己的内部团队工作流程在自己的存储库之间获取/合并。
但是，如果他们想为中央存储库做出贡献，他们必须首先了解该存储库的最新历史。

于 2009-01-20T08:55:38.850 回答
1

DVCS 的主要好处之一是您可以从“官方”存储库中获取最新版本，然后对它进行冒险。您可以在本地提交更改并随意回滚。这也意味着您甚至可以在没有访问中央存储库的情况下工作，并且仍然拥有源代码控制的好处。

我认为只要有一点纪律，这个模型就可以很好地工作。本文很好地解释了您可以采用的各种模型

于 2009-01-20T10:46:14.290 回答
0

像 Git 这样的 DVCS 不会强迫您使用中央存储库。当然，可以将一个存储库声明为“中央”或“官方”或其他任何内容，并且在公司环境中，中央存储库是有意义的——如果不是为了开发，那么至少是为了备份目的。

于 2009-01-20T09:05:24.603 回答