来自Linus 本人的这条消息可以帮助您解决其他一些限制

[…] CVS，即它实际上最终非常面向“一次一个文件”模型。

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

Git 从根本上说从来没有真正关注过整个 repo。即使你稍微限制了一些事情（即只检查一部分，或者让历史回溯一点），git
最终仍然总是关心整个事情，并随身携带知识。

所以如果你强迫 git 把所有东西都看成一个 巨大的 存储库，那么它的扩展性就会非常糟糕。我不认为这部分是真正可以修复的，尽管我们可能可以改进它。

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

在我的另一个答案)中查看更多信息：Git
的限制是每个存储库必须代表“一组连贯的文件”，即“所有系统”本身（您不能标记“存储库的一部分”）。
如果您的系统由自治（但相互依赖）部分组成，则必须使用 submodules 。

正如Talljoe 的回答所示，限制可以是 系统 的（大量文件），但如果您了解 Git 的本质（关于由其 SHA-1
键表示的数据一致性），您将意识到真正的“限制”是一种 用法 ：即，您不应尝试将 所有内容 存储在 Git
存储库中，除非您准备始终获取或标记所有内容。对于一些大型项目，这是没有意义的。

如需更深入地了解 git 限制，请参阅“带有大文件的 git ” （其中提到 git-lfs ：在 git存储库之外存储大文件的解决方案。GitHub，2015 年 4 月）

限制 git repo 的三个问题：

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

最近的一个线程（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当文件被大量修改时可能会很慢。