Git在大型项目中变慢的根本原因是默认配置和操作习惯未适配大仓库，通过启用core.preloadindex和core.fscache、调整pack线程与缓存、改用fetch+ff-only合并、规范稀疏检出流程及团队行为约束，可显著提速。
大型项目中 Git 变慢，根本原因不是“Git 本身慢”，而是默认配置和操作习惯没适配大仓库场景。直接改几个关键配置 + 换掉两个高频命令，就能让 git status 从 5 秒降到 0.3 秒，git pull 不再卡在 “Resolving deltas”。
core.preloadindex 和 core.fscache 必须开
这两个配置是大型仓库提速最立竿见影的组合，尤其当项目文件数超过 1 万时效果明显：
-
core.preloadindex true让 Git 并行加载索引（非单线程扫描），对git status、git add加速 30%–60% -
core.fscache true启用文件系统缓存，避免重复 stat() 系统调用；Windows 用户额外加core.protectNTFS false可再快 10%–20% - 注意：两者都依赖本地磁盘 I/O 性能，SSD 下效果远优于 HDD
pack.threads 和 pack.deltaCacheLimit 要按机器调
打包阶段（如 git pull、git gc）卡顿，90% 是因为线程或缓存没设对：
Git Hub Projects V2
下载
使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。
-
pack.threads 0表示自动用满 CPU 核心数；若开发机只有 2 核，可显式设为2避免调度开销 -
pack.deltaCacheLimit默认是 10MB，大仓库建议提到2g（2GB），否则 delta 解包反复刷盘 - 别乱设
core.compression 9：压缩率越高越耗 CPU，日常开发设1或3更平衡
git pull 改成 git fetch + git merge --ff-only
git pull 在大仓库里容易卡住，不是网络问题，而是它默认做了三件事：fetch + 自动 merge + 启动合并策略检查。其中合并策略检查（尤其是非 fast-forward 场景）会遍历大量提交对象：
- 拆成两步：
git fetch（只下载对象）+git merge --ff-only origin/main（仅允许快进，不触发复杂合并逻辑） - 如果确实需要非快进合并，用
git merge --no-ff显式控制，比pull更可控 - CI/CD 脚本中务必禁用
git pull，全部替换为fetch+ 显式合并
稀疏检出 + 浅克隆不能一起用错顺序
很多人试过 git clone --depth=1 --filter=blob:limit=1m 后立刻 git sparse-checkout set src/frontend，结果发现文件还是全下了——这是因为没加 --no-checkout：
- 正确顺序必须是：
git clone --depth=1 --filter=blob:limit=1m --no-checkout <url> - 然后
cd <repo>→git sparse-checkout set src/frontend→git checkout - 漏掉
--no-checkout，Git 会在 clone 结束时自动执行一次完整检出，前面所有 filter 都白设 - 后续
git pull仍只拉取 sparse 目录内变更，但git checkout .会破坏整个瘦身状态，绝对禁止
真正难的不是记参数，而是在团队里统一约束行为：比如禁止 git checkout .、要求 CI 使用 fetch + ff-only merge、新成员克隆必须带 --no-checkout。这些细节一旦松动，优化效果会在两周内归零。
