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

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

1> VonC..：

---

来自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的三个问题:

大文件(包文件的xdelta仅在内存中,对大文件不好)

大量的文件,这意味着,每个blob一个文件,慢git gc一次生成一个packfile.

large 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 当文件被大量修改时可能会很慢.

---

@ Thr4wn:有关GitPro子模块页面的更多信息,另请参阅http://stackoverflow.com/questions/1979167/git-submodule-update/1979194#1979194.对于较短的版本:http://stackoverflow.com/questions/2065559/using-two-git-repos-in-one-folder/2065749#2065749

2> Talljoe..：

---

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

但是有一个实际的限制.我有一个大约8GB的存储库,大于880,000,git gc需要一段时间.工作树相当大,因此检查整个工作目录的操作需要相当长的时间.这个repo仅用于数据存储,所以它只是一堆处理它的自动化工具.从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    .

3> Brian Carlto..：

---

如果你添加太大的文件(在我的情况下是GB,Cygwin,XP,3 GB RAM),那么期待这个.

致命:内存不足,malloc失败了

更多细节在这里

更新3/2/11:使用Tortoise Git在Windows 7 x64中看到类似的内容.使用大量内存,系统响应非常慢.

4> CharlesB..：

---

早在2012年2月,来自Joshua Redstone 的Git邮件列表中就有一个非常有趣的帖子,这是一个Facebook软件工程师在一个巨大的测试库上测试Git:

测试repo有400万次提交,线性历史和大约130万个文件.

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

---

+1有趣.这回应了[我自己关于git限制的答案](http://stackoverflow.com/a/19494211/6309),详细说明了对大文件/文件/包文件数量的限制.