Git 仓库瘦身是版本控制维护中的常见需求。当仓库体积膨胀到影响克隆速度或磁盘占用时，你需要一套清晰的判断路径：先诊断体积来源，再选择清理工具，最后处理协作影响。本文直接提供这套流程，并指出关键取舍与失败条件。
第一步：诊断仓库体积来源
在动手清理前，必须确认体积来自哪里。常见来源有三类：误提交的大文件（如二进制资源、日志）、历史中反复修改的大文件（每次修改都会生成新对象），以及无关对象（如被覆盖的分支或标签）。
使用 git count-objects -vH 查看对象总数和大小，再用 git rev-list --objects --all 列出所有对象，结合 git verify-pack 找出体积最大的 blob。注意：git count-objects 显示的是“松散对象”大小，打包后（git gc）会变小，但历史中的大文件仍会占据 pack 空间。
第二步：确认清理目标与协作影响
清理历史对象本质是重写历史，这会改变所有提交的哈希值。如果仓库有协作者，他们必须重新克隆或执行 git pull --rebase，否则会出现分叉。因此，在操作前必须与团队沟通，并确保所有本地变更已提交或备份。
另一个关键点：任何清理工具都无法删除仍被引用的大文件。如果大文件存在于最新提交中，必须先从工作树和索引中移除（git rm --cached），并更新 .gitignore 防止再次提交。
第三步：使用 git filter-repo 进行精确清理
推荐使用 git filter-repo（官方推荐的新工具，替代 filter-branch）。它速度快、易用，且默认安全（会备份原始仓库）。安装后，运行：
git filter-repo --path path/to/large/file --invert-paths
这会从所有历史中删除该路径。若要按大小过滤，可用 --strip-blobs-bigger-than 10M。filter-repo 会自动运行 git gc 并清理 refs，但你需要手动推送强制更新：
git remote add origin <remote-url>
git push --force --all
注意：filter-repo 会移除原有 remote 配置（出于安全），需重新添加。另外，它默认删除所有 tags，如需保留请用 --refs 参数指定。
第四步：使用 BFG 应对简单场景
BFG Repo-Cleaner 是另一款流行工具，适合删除特定文件或替换文本。它比 filter-repo 更易用，但功能较少。基本用法：
bfg --delete-files '*.zip' my-repo.git
BFG 需要裸仓库（git clone --mirror），操作后同样需要强制推送。注意：BFG 不会自动处理 commit 信息中的引用，若大文件出现在 commit message 中，需额外处理。
第五步：清理本地对象并优化仓库
无论用哪种工具，操作后都应执行 git reflog expire --expire=now --all 和 git gc --prune=now --aggressive 来清除旧对象。但注意：这些命令只影响本地仓库，远程仓库需通过强制推送更新。
若想彻底清理远程，可考虑删除并重建远程仓库（如果托管平台支持），但这样会丢失 issues 和 PR 关联，通常不推荐。
常见误区与失败条件
- 误区：只删除当前文件，不重写历史。 大文件仍存在于历史对象中，仓库体积不会减小。
- 误区：在已推送的仓库上直接强制推送。 会导致协作者仓库分叉，必须提前通知。
- 失败条件：filter-repo 在 Windows 上可能遇到路径大小写问题。 使用
--path时需精确匹配，或改用--path-glob。 - 失败条件：BFG 无法处理 commit 信息中的大文件引用。 需结合 filter-repo 或手动修改 commit message。
- 误区：清理后不验证。 应使用
git count-objects -vH检查体积，并确认关键文件仍在。
总结与后续维护
Git 仓库瘦身的关键在于判断体积来源、选择合适工具、协调协作影响。对于新项目，建议从一开始就使用 Git LFS 管理大文件，避免历史膨胀。若仓库已臃肿，filter-repo 是首选，BFG 适合简单场景。清理后，可参考分支管理最佳实践 和 常见错误处理 来维护仓库健康。
参考资料
- Python 官方文档（用于脚本辅助清理时的参考）
- MDN Web 开发文档（用于 Web 相关大文件处理参考）
延伸阅读