如何处理大型 git 存储库？答案

【问题标题】：How to handle a large git repository?如何处理大型 git 存储库？
【发布时间】：2012-10-03 02:00:30
【问题描述】：

我目前正在将 git 用于大型存储库（大约 12 GB，每个分支的大小为 3 GB）。此存储库包含大量二进制文件（音频和图像）。

问题是克隆和拉取可能需要很多时间。特别是“解决增量”步骤可能非常长。

解决此类问题的最佳方法是什么？

我试图移除 delta 压缩，因为它解释了 here 使用 .gitattributes 中的 delta 选项，但它似乎没有改善克隆持续时间。

提前致谢

凯文

【问题讨论】：

标签： git

【解决方案1】：

2015 年 4 月更新：Git Large File Storage (LFS)（来自 GitHub）。

它使用git-lfs（参见git-lfs.github.com）并在支持它的服务器上进行了测试：lfs-test-server：
您只能将元数据存储在 git 存储库中，并且其他地方的大文件。

原始答案（2012 年）

对于大型二进制文件变化不大，一种解决方案是将它们存储在不同的引用中（如Nexus repository），并且仅版本化一个文本文件，声明您需要哪个版本。
使用“工件存储库”比在 source 存储库中存储二进制元素更容易（用于比较版本和分支之间的合并，这对所述二进制文件没有多大用处）。

另一个更以 git 为中心的解决方案是 git-annex：

git-annex 允许使用 git 管理文件，而无需将文件内容检查到 git。
虽然这看起来很矛盾，但在处理比 git 目前可以轻松处理的文件时，它很有用，无论是由于内存、时间或磁盘空间的限制。

但它与 Windows 不兼容。

更通用的解决方案可能是git-media，它还允许您将 Git 与大型媒体文件一起使用，而无需将媒体存储在 Git 本身中。

最后，最简单的解决方案是将这些二进制文件隔离在自己的git submodule 中，正如您在问题中提到的那样：它不是很令人满意，初始克隆仍需要一些时间，但父回购的下一次更新会很短。

【讨论】：

感谢您的建议。 Nexus 似乎很有趣，它可能在其他几种情况下很有用。当我有时间的时候我会看看这个:)。 git-annex 可能是解决我当前问题的更快方法。
git-annex 与 Windows 不兼容，我需要 MacOS 和 Windows :(。我将取消选中答案，直到我有时间尝试 Nexus 看看是否有人有其他解决方案。再次感谢。
@KevinMOLCARD 没问题。我添加了替代品（请参阅我编辑的答案）
感谢@VanC 的更新，我会检查 git-media。对于我不知道的子模块，因为我有一个构建服务器，它每天都在进行新的克隆。
@KevinMOLCARD 新克隆不必递归（即不必包含所有子模块）：它可以扫描父仓库的.gitmodules 文件，并检测是否有任何子模块SHA1 有变化，仅触发对正确（即修改后的）子模块的提取。

【解决方案2】：

按照这些步骤操作。

1. 输入以下代码，在本地机器上安装 git lfs。

git lfs install

2.现在添加您希望 lfs 为您管理的文件类型。

git lfs track "*.mp4"

【讨论】：