如何排查大型单体仓库CI中git clone/fetch速度缓慢的问题？

一、启用Git内置性能追踪 #

Git自带调试与性能统计工具，可直接定位操作各阶段耗时：

• 开启全局性能日志
  执行以下命令让Git记录所有操作的详细耗时：

  git config --global trace.performance true
  git config --global trace.log "$HOME/git-trace.log"
  

  运行你的检出命令后，查看git-trace.log，日志会列出每个子命令、钩子、网络操作的具体耗时，快速区分是网络拉取还是本地处理拖慢速度。

• 实时追踪操作步骤
  在执行检出命令时附加追踪参数，实时输出各环节耗时：

  GIT_TRACE=1 GIT_TRACE_PERFORMANCE=1 git clone --depth=1 --single-branch $REPO
  

  输出会明确标注fetch-pack、checkout等阶段的耗时，直接锁定瓶颈。

二、排查仓库自身臃肿问题 #

对比react仓库的差异，重点检查仓库特性：

• 定位历史大文件
  即使文件已被删除，历史中的大文件仍可能影响传输效率，用以下命令找出历史中的大对象：

  git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print $1}')"
  

  这类大文件会增加打包传输的负载，导致浅克隆变慢。

• 统计仓库对象规模
  查看仓库的对象总数与总大小，和react仓库做对比：

  git count-objects -vH
  

  如果你的仓库对象数量或总大小远超react，说明仓库臃肿是核心问题。

• 检查Git钩子
  仓库的pre-fetch、post-checkout等钩子脚本可能执行耗时操作，查看当前钩子：

  ls -la .git/hooks/
  

  临时重命名钩子文件（如mv .git/hooks/pre-fetch .git/hooks/pre-fetch.bak）后重新执行检出，若耗时下降则说明钩子是拖慢因素。

三、验证网络链路效率 #

若日志显示网络操作占比高，需排查链路问题：

• 测试服务器网络延迟
  用ping和traceroute测试与Git服务器的连接质量：

  ping <git-server-domain>
  traceroute <git-server-domain>
  

  对比克隆react仓库时的网络耗时，判断是否为特定服务器的链路瓶颈。

• 切换协议测试
  若当前用HTTP/HTTPS协议，尝试切换到SSH协议：

  git clone --depth=1 --single-branch git@<git-server-domain>:<repo-path>.git
  

  部分场景下SSH协议的传输效率优于HTTPS。

四、生成结构化性能报告 #

• 使用Git内置profile工具（Git 2.37+）
  Git 2.37及以上版本支持生成结构化性能报告：

  git profile start
  git clone --depth=1 --single-branch $REPO
  git profile stop
  git profile show
  

  报告按操作类型分类统计耗时，直观展示瓶颈环节。

• 自定义脚本拆分计时
  编写shell脚本拆分检出步骤，单独统计每个环节耗时：

  #!/bin/bash
  echo "=== 初始化仓库 ==="
  time git init
  echo "=== 添加远程仓库 ==="
  time git remote add origin $REPO
  echo "=== 浅拉取指定提交 ==="
  time git fetch --depth 1 origin $COMMIT_HASH
  echo "=== 检出代码 ==="
  time git checkout FETCH_HEAD
  

  执行脚本后可明确各步骤的耗时占比，精准定位慢步骤。

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