是否建议将 Git 用于大型 (>250GB) 内容存储库答案

【问题标题】：Is Git recommended for large (>250GB) content repositories是否建议将 Git 用于大型 (>250GB) 内容存储库
【发布时间】：2010-11-03 05:45:02
【问题描述】：

网络应用程序是一个定制的 CMS，它有多个子应用程序，每个子应用程序的代码和内容都位于相同的目录结构中。由于应用程序框架的架构，代码和内容是交织在一起的（内容取决于代码的显示和其他功能），因此是不可分割的。内容不存储为 BLOB，而是存储为文件，底层数据库用于链接它们。子应用程序的大小范围为 20GB - 250GB 甚至更多（这是杀手锏）。

网络应用程序将在代码中进行一些增强（新的子应用程序、错误修复等），同时用户将通过现有系统添加/更新内容。因此，需要部署/发布过程，最重要的是需要为代码和内容建议版本控制系统。

Git 之所以出现是有原因的——它是开源和免费的，易于分支和合并，它不是集中式的，因此没有单点故障。

但是在网络上进行了一些初步研究之后，我发现了一些适用于我们的应用程序的令人失望的事实 - 将 Git 用于像我们这样的大型系统是痛苦的（结帐、克隆、合并、推送、拉取）并且命令很复杂（ “极客”更适合）对于 DVCS 无知且主要是 Windows 用户的开发人员群。

Git 没有固定的思维模式，但如果我必须采用集中式方法（在最糟糕的情况下），那么应该采取什么方式（CVS 和 SVN 除外）。我已经读过 Perforce 是一个稳定的版本，并且在 Google 中也有使用（我希望这里有一些粗鲁！！）。

请分享、指导和评论您的观点。我真的需要他们。

【问题讨论】：

Git 不是为这么大的存储库设计的（尽管正在努力使它对大文件和大型存储库表现得更好）......但我认为你会遇到任何版本控制的性能问题不按文件方式进行操作的系统（这有其自身的严重缺点），或者不支持部分签出。你真的需要对那些大文件和代码进行版本控制吗？
我刚刚读到一个名为 monotone 的 DVCS。可能是您的替代方案。
我目前正在处理一个巨大的存储库。我正在研究子模块，看看这是否能改善一切。

标签： git version-control perforce

【解决方案1】：

我刚好在一分钟前正在阅读this blog post。对 git 的可扩展性有点吐槽。

编辑：八年后，Git 有了 Large File Storage (LFS)，微软正在开源 Git Virtual File System (GVFS)，以便他们可以使用 git 开发 Windows。

【讨论】：

好帖子 :) 嗯，这些问题是可以解决的，还是 git 的设计有问题？
可以解决吗？我不知道。 Linus 设计了 git 来处理 linux 源代码树，它做得非常好。但这几乎是所有文本文件。存储库、结帐和构建对象在我的计算机上总共不到 2GB。
引用的文章非常过时，相关性不高。
链接答案不好；链接失效，或者像这样移动。我们应该在这个答案中至少包含一个次要的描述。
链接的文章有八年了，Git 和 Perforce 都有很大的发展。

【解决方案2】：

git 不适用于大型存储库。这不是空间，而是文件的数量。请阅读我不久前写过的blog article。

根据我的经验，如果您想要一个可扩展、快速、集中的源代码控制系统，P4 是您的最佳选择。

【讨论】：

Perforce 在这个特定问题上非常擅长。皮克斯将它在 Perforce 中拍摄的每部电影的每一帧都存储起来。这是很多数据。这个链接有点 Perforce 宣传，但你不能与它描述的数字争论。它可以很好地扩展。 perforce.com/blog/140924/…

【解决方案3】：

Microsoft 刚刚发布了 Git 虚拟文件系统 (GVFS)，专门用于使用 git 处理大型代码库。 More details here at msdn

还有Microsoft hosts the Windows source in a monstrous 300GB Git repository

我没有任何使用 GVFS 的经验。

【讨论】：

【解决方案4】：

有一个名为 git-split 的实用程序脚本可以分割 git repo 以提高效率。

【讨论】：

【解决方案5】：

SVN 真的是一个糟糕的选择吗？

优点：

可以处理大型存储库，例如许多 linux 发行版都使用它，还有 Apache、Sourceforge
拥有漂亮的 GUI 前端和 TortoiseSVN，让您的 Windows 用户满意
可与 Windows 集成身份验证一起使用，让管理员满意
可以根据您的要求采用许多不同的备份策略（svnadmin hotcopy 或 dump、svnsync、post-commit 挂钩），以帮助缓解单点故障问题。

缺点：

集中式 VCS

免责声明：我从未使用过 Perforce，并且已经成为一名快乐的 SVN 管理员和用户大约 6 年（自 v0.29 起）

【讨论】：

我认为我们正在讨论的文件大小会导致任何系统出现问题 - 单次检出 250GB 的文件，无论 VCS 开销如何，都会非常痛苦网络。
我同意 Sean，但如果他想要 VCS 解决方案，为什么要选择为源代码而不是任何类型的文件设计的系统？
+1 附加缺点：合并不太好。尽管如此，SVN 仍然是一个非常好的工具，而不是应该随意丢弃为“不值得”的东西。
同意，尽管自 1.6 以来合并变得更好，并且在 1.8 中吸收更少;-)

【解决方案6】：

首先，我不同意 Git 不适合非技术用户。是的，有一些新手不会使用的功能（例如 git-send-email）。但也有像 TortoiseGit 这样的 GUI 让简单的事情变得简单。

但是，我认为您的处理方式是错误的。基本上，您的内容会经常更改并且需要由 Joe Bloggs 非常容易地编辑，而代码将不经常被编码人员修改。传统的解决方案是使用真正的 CMS（例如Alfresco、SugarCRM、Drupal 等或 Wiki（MediaWiki、MoinMon 等），并带有可选插件。请记住, wiki（和大多数 CMS）允许以“用户友好”的方式对内容进行版本控制。

即使您必须保留您的内部代码，我认为您仍然应该希望提取内容，以便将它们分开处理。将代码和内容分开后，您的存储库将具有更合理的大小。然后，你可以使用任何你想要的 VCS（虽然我不确定你是否正确，Git 本质上不适合大型 repos）。

【讨论】：

Matthew，你自己用过 TortoiseGit 吗？我没有，但我的印象是它仍然是非常测试版（如果不是 alpha 版）。我曾尝试在 Windows 上使用 MSYS Git，但发现它笨重且独特。而且没有像 TortoiseGit 这样可用的 GUI 界面，真的不适合非技术人员或胆小的人。
Evan，我也没有机会使用它。但是，它基于流行的 TortoiseSVN，并且得到了积极的维护。因此，我绝对认为它是可用的。
我在工作场所对 TortoiseGit 进行了非常简短的试验，因为我们正在评估替代的源代码控制系统。我的非技术测试用户对此完全感到困惑和困惑，并且在几个小时内就表现出积极的敌意。
@Evan 我在 2009 年没有使用 TortoiseGit，但在 2014 年，gui 界面变得如此之好，以至于我使用它比在终端中使用 git 更频繁。
@simonzack 很高兴听到这个消息，很高兴知道。我必须承认我更喜欢 Mercurial（据记录，TortoiseHg 也很好）但下次我需要启动我的 Git-fu 时，我绝对会看看它。

【解决方案7】：

我在一个学校项目（带有 Zend 框架的 php 站点）中只使用了一次 git。

我们使用了 git，但老师需要在 svn repo 上发布最终版本。

比较结帐尺寸：

git checkout 是 svn checkout 大小的一半。

我的两分钱。

【讨论】：

当然，而且它总是会因为 SVN 在您的工作副本（在 .svn 文件夹中）保留一个基本副本。这意味着差异、还原等不需要网络。 SVN 旨在处理低带宽通信（想想拨号）。
git 也保留差异 - 它是分布式版本控制系统，因此您不需要网络即可工作
斯特凡是对的。 SVN 将 /not/ 允许您进行任意差异，仅对您最近的更新进行差异。如果您希望能够大量离线工作，您需要一个真正的 DCVS，而 SVN 不是。
@stefanB 不，git 不使用差异。它会记录您使用的每个不同文件的整个完整文件。使用 gzip 压缩可以提高效率，但它仍然是 repo 曾经拥有的每个文件的每个版本，这与保留差异有很大不同。