一个 8G 的 Git 仓库，我把它瘦到了 600M

上周接手一个跑了四年的老项目，git clone 花了十九分钟，卡在 Receiving objects 60% 那一段。我一开始以为是网络问题，换了三次网络还是一样，才反应过来是仓库本身太胖。

先看体积构成。在仓库根目录敲 git count-objects -vH，size-pack 显示 8.2G。再翻一下到底哪些文件占地方：

git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print $3, $4}' | sort -n | tail -20

排出来前十全是设计给的 psd 和几个演示视频，加起来五个多 G。最大的那个视频 1.4G，2022 年提交过一次，2023 年就删了。删了不等于没了，历史里还在，每次 clone 都得把它完整拉下来。

我用的办法是 git filter-repo，不是 filter-branch。后者太慢，这个仓库跑一遍四十分钟往上，中途断了还得从头来。动手前先备份一份裸库：

git clone --mirror git@xxx/app.git app-backup.git

然后在工作副本里执行 git filter-repo --path assets/video --invert-paths，把整个目录从历史里摘掉。psd 那种零散文件走 --path-glob '*.psd'。跑完再 clone，620M，两分半。

中间踩了两个坑。filter-repo 会把 origin 远程配置删掉，得手动 git remote add origin 加回来，不然 push 直接报没有远程。另一个是所有人本地的旧分支都废了，必须重新 clone，我在群里提前说了一下午，还是有两个人照常 push，报错之后来找我。

后来在 CI 里加了一条检查，单个文件超过 20M 打警告，超过 50M 直接拒绝合并。半年下来没人再往仓库里塞视频了，clone 一直维持在两分钟出头。现在接手新项目，我先看 size-pack 再谈别的。