git verify-pack -v 只能定位大 blob 对象及其所在 pack 文件，无法显示分支信息；需结合 git log --all --objects --grep 和 git branch --contains 逆向追踪，或使用更精准的 git filter-repo --analyze 分析历史路径与分支提示。
git verify-pack -v 能直接定位大文件，但不显示分支信息
它只告诉你哪个 blob 对象最大、在哪个 pack 文件里，但不会告诉你这个 blob 最后一次出现在哪个分支。因为 Git 的对象是全局的，一个 blob 可能被多个提交、多个分支引用。所以光靠 git verify-pack -v 只能拿到“谁胖”，拿不到“谁养的”。
用 git log --all --objects --grep 逆向追踪 blob 所属分支
拿到最大的 blob hash（比如 a1b2c3d...）后，运行：
git log --all --objects --grep="a1b2c3d" --oneline
这会列出所有包含该 blob 的提交，再配合 git branch --contains <commit-hash></commit-hash> 就能知道哪些分支还持有它。实际操作中建议分两步：
- 先用
git verify-pack -v .git/objects/pack/*.idx | sort -k3 -n | tail -10找出 top 10 大 blob - 对每个 blob hash，执行
git log --all -1 --pretty="%h %d" --grep="<hash>"</hash>，%d会显示该提交关联的分支名（含 HEAD、tag 等） - 注意：如果 blob 已被删但未 gc，
git log可能查不到；此时需加--no-merges或限定时间范围避免噪音
git filter-repo --analyze 是更准的现代方案
git filter-repo 自带分析模式，比老式 filter-branch 更快、更可靠。它能直接输出每个大文件的历史路径、首次/末次出现的提交、以及这些提交所属的分支（通过 --mailmap 或 --source 推断）。执行：
git filter-repo --analyze
完成后会生成 .git/filter-repo/analysis/blobs-sizes.txt，里面每行含：size path commit_hash branch_hint。其中 branch_hint 不是绝对准确，但已足够指导清理——比如看到 hotfix/v2.1.0 下反复出现同一个 PSD 文件，就说明问题出在那个修复分支的多次提交里。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
⚠️ 注意：git filter-repo 需要先安装（pip install git-filter-repo），且不能在 Windows PowerShell 默认环境下运行（推荐 WSL 或 Git Bash）。
别忘了检查已删除但未清理的分支残留
很多大文件其实藏在已被 git branch -d 删除的分支里——Git 不会自动删掉它们引用的对象。运行：
git for-each-ref --format='%(refname:short)' refs/heads/
再对比 git branch -a 输出，看是否有远程分支（如 origin/old-feature）本地没删干净。真正要确认是否“彻底无引用”，得用：
git fsck --unreachable --no-reflog
如果输出里有大量 blob 行，说明那些大文件还在对象库中游荡，只是没人指向它们了。这时候 git gc --prune=now 才能真正释放空间——但前提是确认这些 blob 确实不该保留。
真正的难点不在找到大文件，而在于判断“它到底还该不该存在”。有时候一个 100MB 的视频文件，在 docs/ 分支里是合理文档素材，在 feature/login 分支里却是误提交的测试录像。得结合业务上下文看 commit message 和 diff，而不是只盯着 size 排序。
