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

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

128550 次浏览
小开

没有真正的限制——所有东西都以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    .
小开

这取决于你的意思是什么。有一些实际的大小限制(如果您有很多大文件，它会变得非常慢)。如果你有很多文件，扫描也会变慢。

不过，这个模型并没有什么固有的局限性，你当然可以糟糕地使用它，让自己感到痛苦。

小开
最佳答案

这个来自 莱纳斯本人的消息可以帮助您解决一些其他限制

[ ... ] CVS (最终基本上只有一个文件) 模型。

这很好，因为你可以有一百万个文件，然后只检查 其中的一些-你甚至不会 看的影响其他 999995份文件。

从根本上来说，从来没有真正看低于整个回购。即使你 限制一些东西(只看一部分，或让历史过去) Git 最终还是会关心整件事情, 带着知识到处走。

所以如果你强迫它把所有东西看成一个整体，git 的伸缩性会非常差 巨大的 存储库。我不认为这部分是真正可以修复的，虽然我们 也许能改进一下。

是的，还有“大文件”的问题，我真的不知道该怎么办 我们不擅长处理大文件，我知道。

在我的 另一个答案中可以看到更多: Git 的限制是每个存储库必须表示“ 连贯的一组文件”，即“所有系统”本身(不能标记为“存储库的一部分”)。
如果您的系统是由自治的(但是相互依赖的)部分组成的，那么您必须使用 子模块。

如 Talljoe 的回答所示，这个限制可以是 系统(大量文件) ，但是如果你了解 Git 的本质(关于它的 SHA-1键所表示的数据一致性) ，你就会意识到真正的“限制”是 用途: 也就是说，你不应该尝试将 一切存储在 Git 存储库中，除非你准备好总是获取或标记所有内容。对于一些大型项目来说，这毫无意义。

有关 git 限制的更深入信息，请参见“ 带有大文件的 git”
(其中提到了 < a href = “ https://git-lfs.github.com/”rel = “ norefrer”> git-lfs : 一种在 git repo 之外存储大文件的解决方案。 GitHub，2015年4月)

限制 Git 回购的三个问题:

  • 巨大的文件 (包文件的 xdelta只在内存中，这对大文件不好)
  • 大量的文件 ，这意味着，每个 blob 一个文件，并且缓慢的 git gc 一次生成一个包文件。
  • 巨大的包文件 ，包文件索引效率低下，无法从(巨大的)包文件中检索数据。

最近的一个帖子(2015年2月)说明了 Git 回购的限制因素:

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

克隆时服务器中没有锁，所以理论上克隆不会影响其他操作。克隆可以使用大量的内存(和大量的 CPU，除非你打开可达位图功能，你应该)。

git pull会慢吗？

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

git push？

这一条不受回购历史的深度或树的宽度的影响，所以应该快一点。.

参考文献的数量可能同时影响 git-push和 git-pull。
我觉得斯特凡比我更清楚这一点。

‘ git commit’? (它在 < a href = “ http://thread.gmane.org/gmane.comp.version-Control.git/189776”rel = “ noReferrer”> 参考文献3 中被列为慢速。) “ git status”? (参考文献3再次放慢速度，尽管我没有看到它。)
(同样是 git-add)

再说一次，你的树有多大，以你的回购规模，我觉得你不需要担心。

有些操作可能看起来不是日常操作，但是如果它们经常被网络前端调用到 GitLab/Stash/GitHub 等，那么它们就会成为瓶颈。(例如，‘ git branch --contains’似乎受到大量分支机构的严重不利影响。)

当一个文件被大量修改时，git-blame可能会变慢。

小开

我认为尽量避免将大文件提交作为存储库的一部分是很好的(例如，数据库转储可能在其他地方更好) ，但是如果考虑到其存储库中内核的大小，您可能希望能够轻松地处理任何大小较小且不那么复杂的内核。

小开

如果您添加的文件太大(GB 在我的情况下，Cygwin，XP，3GB 内存) ，期望这一点。

内存不足，malloc 失败

更多细节 给你

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

小开

我有大量的数据作为单独的 JSON 片段存储在我的 repo 中。在一些目录下有大约75,000个文件，这对性能并没有什么影响。

第一次检查显然有点慢。

小开

Git 对于回购有4G (32位)限制。

Http://code.google.com/p/support/wiki/gitfaq

小开

回到2012年2月，Joshua Redstone 发布了一个非常有趣的 Git 邮件列表中的线程，他是 Facebook 的软件工程师，在一个巨大的测试库上测试 Git:

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

运行的测试表明，对于这样的回收 Git 是不可用的(冷操作持续几分钟) ，但这可能会在未来发生变化。基本上，对内核 FS 模块的 stat()调用次数会降低性能，因此性能将取决于 repo 中的文件数量和 FS 缓存效率。进一步的讨论请参见 这个要点。

小开

我发现这试图存储大量的文件(35万以上)在一个回购。是的，商店。笑。

$ 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。

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

小开

从2018-04-20开始，使用特定的实现(这个 bug 传播到 lfs) ，Git for Windows 有一个 bug有效地将文件大小限制为最大4GB。


提交答案