我已经在各种互联网资源上看到Git处理大文件的情况不是很好，Git似乎也遇到了大型整体存储库大小的问题。这似乎启动了像git-annex，git-media，git-fat，git-bigfiles等项目，甚至可能更多......
然而，在阅读Git-Internals之后，我认为，像Git的包文件概念应解决大文件的所有问题。
Q1： Git中的大文件有什么大惊小怪？
Q2： Git和大型存储库有什么大惊小怪？
Q3：如果我们的项目有两个二进制依赖项（例如大约25个DLL文件，每个大约500KB到1MB），这些文件每月更新一次。这对Git来说真的会成为一个问题吗？只是初始克隆是一个漫长的过程，或者正在使用存储库（例如分支更改，提交，拉动，推送等）将成为日常问题？
答案 0 :(得分：0)
简而言之，今天的计算机对大文件很糟糕。移动兆字节非常快，但千兆字节需要时间。只有专门的工具可以处理千兆字节的数据，而Git不是其中之一。
更多与Git相关：Git一直在比较文件。如果文件很小（几KB），那么这些操作很快。如果它们很大，那么git必须比较许多字节，这需要时间，记忆和神经。
您列出的项目会为大型文件添加特殊处理，例如将它们保存在单个blob中，而不尝试将它们与以前的版本进行比较。这使得每天的操作更快，但是以存储库大小为代价。并且Git需要按照repo大小的顺序为某些操作提供可用磁盘空间，否则你会收到错误（可能是一个损坏的repo，因为这段代码很容易被测试）。
最后，初始克隆需要很长时间。
关于Q3：Git不是备份工具。您可能不希望能够在十年前获得DLL。
将这些库的源代码放在Git下，然后使用备份/发布过程来处理二进制文件（比如保留过去12个月的价值在某些网络驱动器上）。