git - 为什么 Git 不能处理大文件和大仓库？

Question

SO 和其他地方的许多问题和答案强调 Git 无法处理大文件或大 repo 。建议使用一些解决方法，例如 git-fat和 git-annex ，但理想情况下，Git 会本地处理大文件/存储库。

如果此限制已存在多年，是否有理由尚未取消该限制？我假设 Git 中存在一些技术或设计挑战，这使得大文件和大型存储库支持变得极其困难。

很多相关问题，但似乎没有一个能解释为什么这是一个如此大的障碍:

• git with large files
• What are the file limits in Git (number and size)?
• Git - repository and file size limits
• Versioning large text files in git
• How to handle a large git repository?
• Managing large binary files with git
• What is the practical maximum size of a Git repository full of text-based data? [知乎]

Answer 1

基本上，它归结为权衡。

你的一个问题有一个 Linus 自己的例子:

...CVS, ie it really ends up being pretty much oriented to a "one file at a time" model.

Which is nice in that you can have a million files, and then only check out a few of them - you'll never even see the impact of the other 999,995 files.

Git fundamentally never really looks at less than the whole repo...So git scales really badly if you force it to look at everything as one huge repository...

And yes, then there's the "big file" issues. I really don't know what to do about huge files. We suck at them, I know.

正如您不会找到具有 O(1) 索引访问和插入的数据结构一样，您也不会找到可以出色完成所有工作的内容跟踪器。

Git 故意选择在某些方面做得更好，而损害其他方面。

---

磁盘使用情况

由于 Git 是 DVCS(分布式 版本控制系统)，每个人都有整个存储库的副本(除非您使用相对较新的浅克隆)。

这有一些真的很好的优势，这就是像 Git 这样的 DVCS 变得非常流行的原因。

但是，在带有 SVN 或 CVS 的中央服务器上的 4 TB 存储库是可管理的，而如果您使用 Git，每个人都不会对随身携带它感到兴奋。

Git 具有巧妙的机制，可通过跨文件创建增量链(“差异”)来最小化存储库的大小。 Git 在创建它们时不受路径或提交顺序的限制，而且它们确实工作得很好......有点像压缩整个 repo。

Git 将所有这些小差异放入包文件中。 Delta 链和 packfile 使检索对象花费的时间稍长，但这在最大限度地减少磁盘使用方面非常有效。 (又是那些权衡。)

该机制不适用于二进制文件，因为它们往往会有很大差异，即使在“小”更改之后也是如此。

---

历史

当您 checkin 文件时，您将永远拥有它。您的孙辈的孙辈每次克隆您的存储库时都会下载您的猫 gif。

Git 基于内容的设计(每个对象 ID 都是其内容的 SHA)使得永久删除这些文件变得困难、具有侵入性并且对历史具有破坏性。相比之下，我可以从工件存储库或 S3 存储桶中删除粗糙的二进制文件，而不会影响我的其余内容。

---

难度

处理非常大的文件需要很多 仔细的工作，以确保最小化您的操作，并且永远不会将整个文件加载到内存中。在创建具有像 git 这样复杂的功能集的程序时，要可靠地做到这一点是极其困难的。

---

结论

最终，说“不要将大文件放入 Git”的开发人员有点像那些说“不要将大文件放入数据库”的开发人员。他们不喜欢它，但任何替代方案都有缺点(一种情况下是 Git 集成，另一种情况下是 ACID 合规性和 FK)。实际上，它通常工作正常，特别是如果您有足够的内存。

它不是为此而设计的，所以它不会出类拔萃。