Git 仓库体积病理诊断

要解决的具体问题

仓库体积失控时，最先遭殃的是日常操作：克隆可能跑上几十分钟甚至超时，git fetch 越来越慢，CI 里拉取代码这一步变成瓶颈，新贡献者入职第一天就被庞大的历史挡住。更隐蔽的损耗出现在 git gc 与历史遍历上——对象数量越多，垃圾回收和引用遍历的耗时就越长，且随历史增长非线性上升。

这类问题不会体现在 git status 或提交记录里，往往只留下「仓库越大越慢」的模糊感受。本技能要把这种感受转成可定位的证据，指出拖慢仓库的具体病理特征。

技能如何工作

本技能基于 git-sizer 对本地仓库做离线分析，核心步骤如下：

• 采集大小指标：统计对象总数、blob 体积分布、树体积分布、引用数量等维度。
• 标记病理阈值：对超出合理范围的指标给出警告，例如单个过大 blob、过大的树、引用过多、松散对象过多。
• 输出证据而非命令：结果是「哪个路径下的哪个对象超限」这类可复核的证据，清理建议应基于这些证据再提出。

文档同时给出方向性提示：若发现辅助信息（例如 CI 构建结果）大量挂在标签上，可考虑改用 git notes 记录，避免污染提交历史。

适用边界与注意点

• 分析对象必须是完整的非浅克隆，浅克隆缺少历史，体积指标会失真。
• 需要本地 Git 2.6 或更新版本，否则部分底层命令的输出格式可能无法被正确解析。
• 本技能只负责诊断与给出证据，重写历史、清理旧数据等破坏性操作应在证据基础上另行评估。