我在一台Linux机器上有一个10 GB的存储库，它位于NFS上。第一次执行git status需要36分钟，而随后的git status只需要8分钟。似乎Git依赖操作系统缓存文件。像commit、status这样涉及整个存储库打包/重打包的第一个git命令需要花费很长时间。我不确定您是否在这样大的存储库上使用过git status，但是否有人遇到过这个问题？
我已尝试过git gc、git clean、git repack，但所需时间仍然几乎相同。
子模块或将存储库拆分为较小部分等其他概念是否有帮助？如果有，最适合分割大存储库的方法是什么？还有其他改进在大型存储库中使用git命令所需时间的方法吗？
index.lock文件当你有剩余的index.lock文件时，git status命令可能会变得非常缓慢。
特别是在使用git子模块时，这种情况经常会出现，因为你通常不会注意到这些残留文件。
总结：在检查这些文件确实未被任何当前正在运行的程序使用后，请运行find .git/ -name index.lock命令并删除剩余文件。
我发现我的shell git状态在Ubuntu 16.04上的git 2.19版本下非常缓慢。
我深入研究后发现，我的assets git子模块中的/usr/bin/time git status需要1.7秒。
使用strace发现git使用mmap读取了其中所有大文件。通常情况下，使用stat就足够了。
我搜索了这个问题并找到了使用索引和Racy Git问题。
尝试使用git update-index somefile(在我的情况下是子模块检出中的gitignore)，如此处所示，但失败了。
fatal: Unable to create '/home/niklas/src/myproject/.git/modules/assets/index.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
git status上引发。index.lock文件后，git status立即变快，mmaps消失了，现在快了1000倍以上。find .git/ -name index.lock并删除残留文件。作为测试，请尝试暂时禁用防病毒软件的实时保护。如果这是问题所在，请更换您的防病毒软件。
举个例子：我曾经运行Webroot，但使用Git时需要30到60秒才能完成任何操作。暂停实时保护后，我的原始性能突然恢复了，更新速度在一秒以内，系统快速而敏捷。
我选择Webroot是因为它以对系统性能的最小影响而闻名，但在这种情况下，它却像隐喻般将我的CPU淹没了。
这是一个相当老的问题。尽管如此，我很惊讶没有人评论关于二进制文件在存储库大小方面的问题。
你提到你的git仓库大约有10GB。除了NFS问题和其他git问题（可以通过git gc和git配置更改来解决，如其他答案中所述），由于存储库中大量的二进制文件，git命令（git status、git diff、git add）可能会变慢。git不擅长处理二进制文件。您可以使用以下命令删除不必要的二进制文件（以NetCDF文件为例；在备份git存储库之前）：
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch *.nc' \
--prune-empty --tag-name-filter cat -- --all
git status性能无关。 - nothrow