70GB仓库下Git stash执行缓慢问题咨询与优化方法求助

对于70GB的大型仓库，git stash耗时10秒并非完全异常，但属于可优化的范畴。从你提供的性能追踪日志来看，核心耗时集中在traverse_trees环节，最终对应执行git reset --hard的过程——这是因为git stash底层会先暂存当前工作区变更，再通过reset将工作区恢复到HEAD状态，大型仓库的树遍历和文件状态校验本身就会消耗较多时间。

优化方案 #

1. 只stash指定文件 #

如果仅修改了少量文件，直接指定文件路径进行stash，跳过全仓库遍历：

git stash push <目标文件路径1> <目标文件路径2>

这种方式只会处理你指定的文件，不会扫描整个70GB仓库，能大幅缩短耗时。

2. 调整Git配置优化IO和遍历 #

针对Windows环境和大型仓库，修改以下配置减少开销：

• 确保大小写忽略（适配Windows文件系统特性）：

  git config core.ignorecase true
  

• 开启批量 checkout 模式，减少小文件IO操作：

  git config core.bulkcheckout true
  

• 优化仓库打包参数，提升大仓库处理效率：

  git config pack.window 10
  git config pack.deltaCacheSize 512m
  

3. 清理未追踪文件 #

如果仓库存在大量未被Git管理的文件（比如构建产物、临时文件），git stash会遍历这些文件判断状态。建议：

• 更新.gitignore，排除无需追踪的文件/目录
• 用git clean -n预览无用未追踪文件，确认后用git clean -f清理（注意：此操作会直接删除文件，谨慎执行）

4. 更换Git运行环境 #

你当前使用的是Git for Windows的mingw64版本，可尝试：

• 切换到WSL2下的Git：WSL2的文件系统IO模型更适配Git设计，处理大型仓库性能通常优于Windows原生Git
• 若坚持用Windows原生Git，确保安装最新版本（你当前的2.49.0已较新，但可关注后续版本的性能优化）

5. 用临时分支替代stash #

如果只是临时保存变更，可改用临时分支方案：

# 创建临时分支并保存变更
git checkout -b temp-wip
git add .
git commit -m "WIP: 临时保存变更"

# 回到原分支继续工作
git checkout 原分支名

# 需要恢复变更时
git merge temp-wip

内容的提问来源于stack exchange，提问作者sayanel