此消息来自可以帮助您解决一些其他限制
[...] CVS，即它实际上最终几乎面向“一个文件”
一次”模型。
这很好，因为你可以拥有一百万个文件，然后只检查
其中一些 - 你甚至永远不会see对方的影响
999,995 个文件。
git
从根本上来说，从来没有真正关注过整个仓库。即使你
限制一下事情（即只查看一部分，或者让历史记录消失）
稍微向后退一点），git 最终仍然总是关心整个事情，
并携带知识。
因此，如果你强迫 git 将所有东西视为一个整体，那么 git 的扩展性会非常糟糕huge存储库。我不认为这部分是真正可以修复的，尽管我们
也许可以改进它。
是的，还有“大文件”问题。我真的不知道该怎么办
处理大文件。我知道我们很讨厌他们。
更多内容请见我的其他答案 https://stackoverflow.com/questions/899373/transferring-legacy-code-base-from-cvs-to-distributed-repository-e-g-git-or-mer/899428#899428：Git 的限制是每个存储库必须代表一个“连贯的文件集 https://stackoverflow.com/questions/967817/do-you-version-control-the-invidual-apps-or-the-whole-project-or-both/968477#968477”，“所有系统”本身（您不能标记“存储库的一部分”）。
如果您的系统由自治（但相互依赖）的部分组成，则必须使用子模块 http://git-scm.com/book/en/Git-Tools-Submodules.
如图所示塔尔乔的回答 https://stackoverflow.com/questions/984707/what-are-the-git-limits/984763#984763，极限可以是system一个（大量文件），但如果您确实了解 Git 的本质（关于由 SHA-1 密钥表示的数据一致性），您将意识到真正的“限制”是usage一：也就是说，你不应该尝试存储一切在 Git 存储库中，除非您准备好始终获取或标记所有内容。对于一些大型项目来说，这是没有意义的。
要更深入地了解 git 限制，请参阅“git 处理大文件 https://stackoverflow.com/a/19494211/6309"
（其中提到git-lfs https://git-lfs.github.com/：在 git 存储库之外存储大文件的解决方案。 GitHub，2015 年 4 月）
限制 git repo 的三个问题：
-
巨大的文件 (the 包文件的 xdelta https://stackoverflow.com/a/9478566/6309仅在内存中，这对于大文件来说不好）
-
文件数量巨大，这意味着每个 blob 一个文件，并且 git gc 一次生成一个包文件的速度很慢。
-
巨大的包文件，包文件索引从（巨大的）包文件中检索数据效率低下。
最近的一个帖子（2015 年 2 月）说明了Git 存储库的限制因素 http://www.spinics.net/lists/git/msg246226.html:
来自中央服务器的一些同时克隆是否也会减慢其他用户的其他并发操作？
克隆时服务器没有锁，所以理论上克隆不会影响其他操作。不过，克隆会使用大量内存（以及大量 CPU，除非您打开可达性位图功能，您应该这样做）。
Will 'git pull' 慢一点？
如果我们排除服务器端，树的大小是主要因素，但是你的 25k 文件应该没问题（linux 有 48k 文件）。
'git push'?
这个不受你的仓库历史有多深或你的树有多宽的影响，所以应该很快..
啊裁判的数量可能会影响两者git-push and git-pull.
我认为斯特凡在这方面比我更了解。
'git commit'？ （它被列为慢参考文献3 http://thread.gmane.org/gmane.comp.version-control.git/189776.)
'git status'？ （参考文献 3 再次变慢，尽管我没有看到它。）
（还git-add)
再说一次，你的树的大小。按照您的存储库的大小，我认为您不需要担心它。
有些操作可能看起来不是日常操作，但如果它们被 Web 前端频繁调用到 GitLab/Stash/GitHub 等，那么它们可能会成为瓶颈。 （例如'git branch --contains'似乎受到大量分支机构的严重不利影响。）
git-blame当文件修改很多时，速度可能会很慢。
