Question

有谁知道文件数量和文件大小的Git限制是什么？

Answer 1

来自Linus himself的此消息可以帮助您解决其他一些限制

[...] CVS，即它真的最终面向“一个文件”   在一次“模特。

这很好，你可以有一百万个文件，然后只检查   他们中的一些 - 你甚至不会看到对方的影响   999,995个文件。

GIT中   从根本上说，从来没有真正看过不到整个回购。即使你   限制一些事情（即只检查一部分，或有历史记录   回来一点），git最终仍然关心整个事情，   并传授知识。

如果你强迫它把所有东西看成一个，那么git的表现就会非常糟糕   巨大的存储库。我不认为那部分是可以修复的，尽管我们   可能会改善它。

是的，那就是“大文件”问题。我真的不知道该怎么做   做大文件。我知道，我们很害羞。

在我的other answer中查看更多信息：Git的限制是每个存储库必须代表“coherent set of files”，本身就是“所有系统”（您无法标记“存储库的一部分”））。
如果您的系统由自主（但相互依赖）的部分组成，则必须使用 submodules 。

如Talljoe's answer所示，限制可以是系统一个（大量文件），但如果您确实理解Git的性质（关于由SHA表示的数据一致性） -1键），你会发现真正的“限制”是一个用法：你不应该尝试将所有存储在Git存储库中，除非你准备好了总是得到或标记一切。对于一些大型项目来说，没有任何意义。

要更深入地了解git限制，请参阅“git with large files”
（提及 git-lfs ：在git repo之外存储大型文件的解决方案.GitHub，2015年4月）

限制git repo的三个问题：

巨大文件（xdelta for packfile仅在内存中，对于大文件效果不佳）
大量文件，即每个blob一个文件，慢git gc一次生成一个packfile。
large packfiles ，包文件索引无法从（巨大的）packfile中检索数据。

最近的一个主题（2015年2月）说明了the limiting factors for a Git repo：

来自中央服务器的一些同时克隆是否也会减慢其他用户的其他并发操作？


克隆时服务器中没有锁，因此理论上克隆不会影响其他操作。克隆虽然可以使用大量内存（除非你打开可达性位图功能，否则需要大量的内存）。


'git pull'会慢吗？


如果我们排除服务器端，树的大小是主要因素，但你的25k文件应该没问题（linux有48k文件）。


'git push'？


这个不受你的回购历史有多深，或你的树有多宽的影响，所以应该很快..

啊裁判的数量可能会影响git-push和git-pull   我认为Stefan在这方面比我更清楚。


'git commit'？（它在 reference 3 中列为慢速。）     'git status'？（参考文献3中再次放慢，但我没有看到它。）
    （也git-add）


再次，树的大小。根据您的回购协议规模，我认为您不必担心它。


某些操作似乎不是日常的，但如果它们经常被Web前端调用到GitLab / Stash / GitHub等，那么它们就会成为瓶颈。（例如'git branch --contains'似乎受到大量分支的极大不利影响。）


git-blame在文件被大量修改时可能会很慢。

Answer 2

没有实际限制 - 所有内容都以160位名称命名。文件的大小必须以64位数字表示，因此也没有实际限制。

但是有一个实际的限制。我有一个大约8GB的存储库，大于880,000，而git gc需要一段时间。工作树相当大，因此检查整个工作目录的操作需要相当长的时间。这个repo仅用于数据存储，所以它只是一堆处理它的自动化工具。从回购中提取更改比发送相同数据要快得多。

%find . -type f | wc -l
791887
%time git add .
git add .  6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status  0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G     .
%cd .git
%du -sh .
7.9G    .

Answer 3

如果你添加太大的文件（在我的情况下是GB，Cygwin，XP，3 GB RAM），那么期待这个。

致命：内存不足，malloc失败

更多详情here

2011年3月2日更新：使用Tortoise Git在Windows 7 x64中看到类似的内容。使用了大量内存，系统响应速度非常慢。

Answer 4

早在2012年2月，有一个非常有趣的thread on the Git mailing list来自Joshua Redstone，一位Facebook软件工程师在一个巨大的测试库上测试Git：

测试回购有4百万次提交，线性历史和约130万次文件。

运行的测试显示，对于这样的回购，Git无法使用（冷操作持续几分钟），但这可能在将来发生变化。基本上，性能受到对内核FS模块的stat()调用次数的影响，因此它将取决于repo中的文件数量和FS缓存效率。有关进一步的讨论，另请参阅this Gist。

Answer 5

这取决于你的意思。有实际的大小限制（如果你有很多大文件，它可能会非常慢）。如果你有很多文件，扫描也会变慢。

但该模型并没有真正的固有限制。你当然可以使用它并且很痛苦。

Answer 6

我认为尽量避免将大型文件提交作为存储库的一部分是很好的（例如，数据库转储可能在其他地方更好），但如果考虑到其存储库中的内核大小，您可能会期望与任何尺寸较小且复杂程度较低的东西一起舒适地工作。

Answer 7

我有大量的数据作为单独的JSON片段存储在我的repo中。大约有75,000个文件位于几个目录下，并不会对性能造成太大损害。

第一次检查它们显然有点慢。

Answer 8

我发现这会尝试在回购中存储大量文件（350k +）。是的，存储。笑。

$ time git add . 
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total

Bitbucket documentation的以下摘录非常有趣。

当您使用DVCS存储库克隆，推送时，您正在使用整个存储库及其所有历史记录。实际上，一旦您的存储库大于500MB，您可能会开始看到问题。

... 94％的Bitbucket客户拥有500MB以下的存储库。 Linux Kernel和Android都不到900MB。

该页面上推荐的解决方案是将项目拆分为更小的块。

Answer 9

截至2018-04-20 Git for Windows has a bug，使用该特定实现有效地将文件大小限制为4GB（此错误propagates to lfs as well）。

Answer 10

git对回购有限制为4G（32位）。

http://code.google.com/p/support/wiki/GitFAQ

Git中的文件限制是多少（数量和大小）？

10 个答案: