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

Question 1

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

Question 2

这从消息Linus本人可以帮助您与其他一些限制

CVS，也就是说，它实际上最终几乎是针对“一次一个文件”模型的。

很好，因为您可以拥有一百万个文件，然后仅检出其中的几个文件-您甚至看不到其他999,995个文件的影响。

从根本上讲，Git从来不会真正关注整个回购。即使您对内容进行了一些限制（例如，仅检查一部分，或者仅回顾了一下历史），git最终仍然总是关心整个内容，并带走了知识。

因此，如果您强迫git将所有内容视为一个巨大的存储库，它的缩放比例将非常糟糕。我认为该部分不是真正可修复的，尽管我们可能会对此进行改进。

是的，然后是“大文件”问题。我真的不知道该如何处理大文件。我知道我们吸他们。

在我的其他答案中查看更多内容：Git的局限性在于，每个存储库都必须表示一个“连贯的文件集”，即“所有系统”本身（您不能标记“存储库的一部分”）。
如果您的系统是由自治的（但相互依存）的部分组成的，则必须使用子模块。

如Talljoe的答案所示，限制可以是系统限制（大量文件），但是如果您确实了解Git的性质（关于SHA-1密钥表示的数据一致性），那么您将认识到真正的“限制”这是一种用法：即，除非您准备总是获取或标记所有内容，否则不要尝试将所有内容存储在Git存储库中。对于某些大型项目，这没有任何意义。

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

限制git repo的三个问题：

大型文件（packfile的xdelta仅在内存中，对于大型文件则不好）
大量的文件，这意味着每个blob一个文件，并且缓慢的git gc一次生成一个packfile。
巨大的packfiles，其中packfile索引无法从（巨大的）packfile中检索数据。

最近的主题（2015年2月）说明了Git回购的限制因素：

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

克隆时服务器中没有锁，因此理论上克隆不会影响其他操作。但是，克隆会占用大量内存（除非您启用了可达性位图功能，否则就会占用大量cpu）。

会git pull慢吗？

如果我们排除服务器端，则树的大小是主要因素，但是25k文件应该很好（Linux有48k文件）。

' git push'？

不受回购记录的历史深度或树的宽度影响，因此应尽快。

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

' git commit'？（在参考文献3中被列为慢速）git status。（尽管我没有看到它，在参考文献3中又变慢了。）
（也git-add）

同样，您的树的大小。按照您的仓库大小，我认为您无需担心。

有些操作似乎不是日常操作，但是如果Web前端经常将它们调用到GitLab / Stash / GitHub等，则它们可能会成为瓶颈。（例如，“ git branch --contains”似乎受到大量分支的不利影响。）

git-blame 大量修改文件时，速度可能会很慢。

Question 3

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

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

%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    .

Question 4

如果添加的文件太大（在我的情况下为GB，Cygwin，XP，3 GB RAM），则可以预期。

严重的：内存不足，malloc失败

在这里更多细节

更新3/2/11：在Windows 7 x64中使用Tortoise Git看到了类似的结果。使用了大量的内存，系统响应非常慢。

Question 5

早在2012年2月，来自Joshua Redstone的Git邮件列表中就有一个非常有趣的话题，这是Facebook软件工程师在庞大的测试存储库中测试Git的：

该测试仓库有400万次提交，线性历史记录和约130万个文件。

运行的测试表明，对于这样的仓库，Git是不可用的（持续几分钟的冷操作），但是将来可能会改变。基本上，性能会受到对stat()内核FS模块的调用次数的影响，因此，它取决于存储库中的文件数以及FS缓存效率。另请参见本要点以进行进一步讨论。

Question 6

截至2018-04-20 ，Windows的Git有一个错误，该错误使用该特定实现将文件大小有效地限制为最大4GB（此错误也传播到lfs）。

Question 7

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

不过，该模型并没有真正的固有限制。您当然可以不好地使用它，并且痛苦不堪。

Question 8

我认为最好避免将大文件提交作为存储库的一部分（例如，数据库转储可能会比其他地方更好），但是如果考虑存储库中内核的大小，则可以期望工作舒适尺寸更小，更简单的东西。

Question 9

我有大量的数据作为单独的JSON片段存储在我的存储库中。大约75,000个文件位于几个目录下，这对性能没有太大影响。

第一次检查它们显然很慢。

Question 10

我发现这试图在存储库中存储大量文件（超过350k）。是的，存储。笑

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

以下来自Bitbucket文档的摘录非常有趣。

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

... 94％的Bitbucket客户的存储库小于500MB。Linux内核和Android都在900MB以下。

该页面上建议的解决方案是将您的项目分成较小的块。

Question 11

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

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