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

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

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

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

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

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

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

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

有关git限制的更深入了解，请参阅“ 带有大文件的git ”
（提到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 大量修改文件时，速度可能会很慢。