为什么Git无法处理大文件和大型代码库？
5
基本上，问题归结为权衡取舍。
你的一个问题有来自Linus自己的例子：
...CVS，也就是说它实际上几乎是面向“一次一个文件”的模型。
这很好，因为你可以有一百万个文件，然后只检出其中的一些——你甚至不会看到其他999,995个文件的影响。
Git从根本上来说永远不会真正查看少于整个存储库的部分......所以，如果你强制Git将所有内容视为一个巨大的存储库来查看，那么它的扩展性就会非常糟糕......
还有，确实存在“大文件”问题。我真的不知道该怎么处理巨大的文件。我知道我们做得很糟糕。
就像你不能找到具有O(1)索引访问和插入的数据结构一样，你也不会找到一个完全出色的内容跟踪器。
Git已经选择在某些方面表现更好，而在其他方面则受到了损害。
磁盘使用
由于Git是DVCS（分布式版本控制系统），每个人都有整个存储库的副本（除非你使用相对较新的浅克隆）。
这具有一些非常好的优点，这就是为什么像Git这样的DVCS已经变得极其流行的原因。
然而，在拥有4TB在SVN或CVS中心服务器上的存储库时，它是可以管理的，而如果你使用Git，每个人都无法携带那么多数据。
Git具有巧妙的机制，通过在文件之间创建增量链（“diffs”）来最小化您的存储库大小。Git在创建这些时不受路径或提交顺序的限制，并且它们确实非常有效......就像压缩整个存储库一样。
Git将所有这些小差异放入packfiles中。增量链和packfiles使检索对象需要更长时间，但它非常有效地最小化了磁盘使用情况。（再次涉及到权衡取舍。）
对于二进制文件，这种机制效果不佳，因为它们往往会发生相当大的变化，即使是一些“小”的更改。
历史
当您检入文件时，它将永远存在。您的子孙后代的子孙每次克隆您的代码库时都将下载您的猫gif。
Git的基于内容的设计（每个对象ID都是其内容的SHA）使得永久删除这些文件变得困难、具有侵入性，并破坏了历史记录。相比之下，我可以从构件存储库或S3存储桶中删除冗杂的二进制文件，而不影响我的其他内容。
难度
处理非常大的文件需要很多仔细的工作，以确保最小化操作，并且永远不会在内存中加载整个文件。当创建像Git这样具有复杂功能集的程序时，要可靠地执行此操作极其困难。
结论
最终，那些说“不要在Git中放置大文件”的开发人员有点像那些说“不要在数据库中放置大文件”的人。他们不喜欢它，但是任何替代方法都有缺点（在一种情况下是Git集成，在另一种情况下是ACID合规性和FK）。实际上，它通常可以正常工作，特别是如果您拥有足够的内存。
它不是为这个而设计的，所以它不会做得很好。
像git-annex这样的替代方案和附加组件将大型二进制文件的修订版本分别存储在一种方式中，该方式打破了git通常具有的离线可用的每个先前状态的假设，但避免了必须发送如此大量的数据。
这是因为每个检出都保存了每个文件的每个版本。
现在，Git 有一些缓解此问题的方法，例如二进制差异和稀疏克隆，但肯定每个客户端都会至少有两份副本（一个在工作树中，一个在仓库中）的每个文件。是否对您构成问题取决于您的情况。
原文链接