包包和糖葫芦1. 为什么你的Git仓库越来越胖？
每次打开终端准备拉取代码时，等待进度条的时间都够冲一杯咖啡？别急着怪网络，很可能是你的Git仓库悄悄"发福"了。我最近就遇到一个12GB的仓库，实际代码才几百MB，罪魁祸首就是.git/objects/pack里那些被遗忘的"脂肪"。
Git的objects目录就像个永不删除的回收站。你每次git add一个文件，Git就会创建对应的blob对象；执行commit时又会生成tree和commit对象。这些对象被打包成.pack文件后，即使你删除了原始文件，它们依然顽固地占据着空间。我见过最夸张的案例是某团队把node_modules误提交后，仓库直接膨胀到20GB+。
常见"增重元凶"包括：
- 构建产物（如dist目录）
- 多媒体资源（视频/PSD源文件）
- 数据库导出文件
- 开发环境依赖（如第三方SDK）
bash复制# 快速检查仓库体积
du -sh .git # 查看.git目录大小
git count-objects -v # 查看对象统计
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 揪出仓库里的"大胃王"
要解决这个问题，首先得找到那些占用空间的历史文件。我习惯用组合命令来场"仓库体检"：
bash复制# 找出体积最大的3个文件
git verify-pack -v .git/objects/pack/pack-*.idx |
sort -k 3 -n |
tail -3
这个命令链的工作原理是：
verify-pack解析pack文件内容sort -k 3按文件大小排序（第3列为压缩前大小）tail显示最大的几个对象
拿到文件哈希后，再用侦探命令追溯真身：
bash复制git rev-list --objects --all |
grep 可疑文件哈希
最近帮某电商团队排查时，发现他们3年前的一次活动页打包文件（1.2GB的zip）竟然还在历史记录里。虽然早就不需要了，但每次克隆都要拖这个"僵尸文件"。
3. 给仓库做"抽脂手术"
找到目标后，就该用filter-branch这个"手术刀"了。这是最关键的步骤，建议先在备份分支操作：
bash复制git filter-branch --force --ind