Git中的文件限制是什么（数量和大小）？
有谁知道什么是文件数量和文件大小的Git限制？
这个来自Linus的消息可以帮助你一些其他的限制
CVS，也就是说，它最终的目标是“一次一个文件”模式。
哪一个是好的，你可以有一百万个文件，然后只检查其中的几个 – 你永远不会看到其他999,995文件的影响。
从根本上说，Git从来没有看到整个回购。 即使你限制了一些东西（比如只检查一部分，或者让历史回溯一点点），git最终还是会一直关心整个事情，并把知识带到身边。
所以如果你强迫它把一切看作一个巨大的存储库，那么git会非常糟糕。 我不认为这个部分是可以修复的，尽pipe我们可以改进它。
是的，那就是“大文件”问题。 我真的不知道如何处理大文件。 我知道，我们吮吸他们。
在我的另一个答案看到更多的：Git的限制是每个存储库必须代表一个“ 连贯的文件集 ”，“所有系统”本身（你不能标记“存储库的一部分”）。
如果您的系统由自主（但相互依赖）部件组成，则必须使用子模块 。
正如Talljoe的回答所示 ，限制可以是一个系统 （大量的文件），但是如果您了解Git的性质（关于由其SHA-1键表示的数据一致性），您将意识到真正的“极限”是一个用法 ：即，除非您准备总是获取或标记所有内容，否则不应该尝试将所有内容都存储在Git存储库中。 对于一些大型项目来说，这是没有意义的。
要更深入地了解git限制，请参阅“ 使用大文件的git ”
（其中提到git-lfs ：在git仓库之外存储大文件的解决scheme，GitHub，2015年4月）
限制git回购的三个问题：
- 巨大的文件 （ Packer的xdelta只在内存中，这对于大文件来说是不好的）
- 大量的文件 ，这意味着，每blob一个文件，并慢git gc一次生成一个packfile。
- 巨大的packfiles ，packfile索引效率低下，从（巨大的）packfile中检索数据。
更新的主题（2015年2月）说明了Git回购的限制因素 ：
来自中央服务器的几个同步克隆是否也会减慢其他用户的其他并发操作？
克隆时服务器没有锁，所以理论上克隆不会影响其他操作。 克隆可以使用大量的内存（除非你打开可达性位图function，你应该使用大量的cpu）。
会“
git pull”缓慢吗？如果我们排除服务器端， 你的树的大小是主要的因素 ，但你的25K文件应该罚款（Linux有48K文件）。
'
git push'？这一个不受你的回购的历史有多深，或者你的树有多宽，所以应该是快的..
啊，裁判的数量可能会影响
git-push和git-pull。
我认为斯蒂芬在这方面比我更了解。'
git commit'？ （它在参考文献3中被列为慢）。'git status'？ （虽然我没有看到它，但在参考文献3中再次放慢速度。）
（也是git-add）再次，你的树的大小。 在你的回购规模上，我不认为你需要担心。
有些操作似乎不是日常的，但如果它们被Web前端频繁地调用到GitLab / Stash / GitHub等，那么它们可能会成为瓶颈。 （比如'
git branch --contains'似乎受到大量分支的严重不利影响。）当文件被修改很多时，
git-blame可能会很慢。
没有实际限制 – 所有内容都以160位的名字命名。 文件的大小必须可以用64位数字表示，所以在这里也没有真正的限制。
虽然有一个实际的限制。 我有一个存储库是〜8GB大于88万和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 .
如果你添加的文件太大（在我的情况下是GB，Cygwin，XP，3 GB的RAM），期待这一点。
致命的：内存不足，malloc失败
更多细节在这里
更新3/2/11：与Tortoise Git在Windows 7 x64中相似。 使用的内存吨，非常非常慢的系统响应。
回到2012年2月， Git邮件列表上的一个非常有趣的线程是 Joshua Redstone，一位testingGit的Facebook软件工程师在一个巨大的testing库中：
testing回购有400万个提交，线性历史和大约130万个文件。
testing表明，对于这样的回购Git是无法使用（冷操作持续几分钟），但这可能会改变将来。 基本上，性能受到内核FS模块的stat()调用次数的惩罚，所以它将取决于repo中的文件数量和FScaching效率。 进一步讨论请参见本要点 。
这取决于你的意思是什么。 有实际的大小限制（如果你有很多大文件，它可以无聊地慢）。 如果你有很多文件，扫描也可能变慢。
虽然这个模型并没有真正的内在限制。 你当然可以使用它，很可悲。
我认为尽量避免大文件提交作为存储库的一部分是很好的（例如，数据库转储可能在其他地方更好），但是如果考虑到存储库中内核的大小，那么可以期望工作起来很舒服比任何东西都小一些，比那个复杂得多。
我有大量的数据存储在我的回购单独的JSON片段。 大约有75,000个文件位于几个目录下，对性能没有任何不利影响。
第一次检查他们显然有点慢。
我发现这试图在回购中存储大量的文件（350k +）。 是的，存储。 笑。
$ time git add . git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total
下面的Bitbucket 文档中的提取是非常有趣的。
当您使用DVCS存储库克隆工作时，您正在使用整个存储库及其所有历史logging。 实际上，一旦您的存储库大于500MB，您可能会开始看到问题。
… 94％的Bitbucket客户拥有500MB以下的软件仓库。 Linux内核和Android都在900MB以下。
该页面推荐的解决scheme是将您的项目分成更小的块。
git有一个4G（32位）回购限制。
