使用中央存储库是否违反GIT的目的?

时间:2009-01-20 08:49:23

标签: svn git dvcs

如果您处于公司设置中,并且有很多人在处理某个特定应用程序,那么它是否会违反distributed version control系统的内容来建立官方中央存储库?

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

是否以与GIT类似的方式使用SVN来破坏{{3}}的目的,并且每个人都推动/拉出中央存储库?每次我想到这样做,我都觉得我错过了一切。

有人可以启发我吗?

7 个答案:

答案 0 :(得分:29)

不是真的。 DCVS只允许在不涉及中央存储库的情况下更自由地在开发人员之间进行交互。官方存储库仅以官方协商一致。 Linux还有一个中央存储库,即创建“官方”内核版本的存储库,但中央“官方”存储库和客户端存储库与集中式VCS之间没有任何物理差异。

答案 1 :(得分:29)

您可能正在考虑这个图表:

alt text

这可能看起来像来自CVCS的混乱。 “我们需要一些订单”,我听到你说了吗?

  

如果您没有中央存储库,那么PITA不会确定谁拥有最新更新版本,具有x或每个人需要抓取的错误修复等等等等等。

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

有点像这样:

alt text

值得注意的是,根据组织内部人员的意愿,可能存在多个感知中央存储库。

想象一下,一个管理多个开发团队的项目经理,每个团队可能都有一个“中心”存储库,他们会推送到这个存储库。每周,项目经理可能会将每个团队的变更提取到他的“中央”存储库中,合并它们并将它们推回到团队的“中央”存储库中。

这可能不是一个很好的例子(我仍然在考虑所有这些),但这只是一个项目经理。再投入一些项目/经理和QA团队,然后你可能会看到我来自哪里......

-

答案 2 :(得分:8)

通过分布式源代码控制,中央“官方”存储库由策略建立 - 而不是源代码控制工具架构。

答案 3 :(得分:6)

绝对没有打败Git的目的。

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

然后,当所有工作完成后,您可以清理历史记录并将完成的更改以统一,干净的状态推送到中央存储库。

我认为你不能低估分离“私人”提交和“公共”推动的想法的优势。它允许跟踪更改,即使您是唯一一个从如此小的粒度中受益的人。

答案 4 :(得分:4)

如果你查看Presentation of Git,(幻灯片475及以下),Git完全支持中央存储库模型。

您可以强制任何希望git push其发展的人首先先制作git fetch + git merge,然后再推送。

这根本没有打败Git的目的,并确保每个人彼此“同步”。

与Linus的“官方”存储库mentionned by JesperE的区别在于它由不同的工作流管理,即“独裁者和中尉”模型,其中写访问(推送)仅授予Linus,并且读取被授予任何人。

现在:“这会破坏DVC的意义吗?”

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

答案 5 :(得分:1)

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

我认为这种模式非常有效。 This article很好地解释了您可以采用的各种模型

答案 6 :(得分:0)

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