git filter-branch 不该用于分支级清理，因其默认重写所有引用（含 tags、远程分支），不保护 head，参数错误易致工作区清空且无快速回退；依赖 shell 脚本导致跨平台转义不一致，执行慢、内存占用高，且自 git 2.22 起已被官方弃用。

BFG 是清理分支历史大文件的首选，filter-branch 已过时且风险高，不建议在真实分支上直接使用。

为什么 filter-branch 不该用于分支级清理

filter-branch 会逐提交重写整个历史链，哪怕只清理一个分支，它仍默认扫描并重写所有引用（包括 tags、refs/remotes/*），极易误伤其他分支。更关键的是：它不保护 HEAD，一旦命令参数写错（比如路径漏了引号、--invert-paths 忘加），当前工作区可能被清空，且无快速回退机制。

• 它依赖 shell 脚本，不同系统（尤其是 Windows CMD）转义行为不一致，git filter-branch --tree-filter 'git rm -f *.log' -- --all 在 Bash 可能成功，在 PowerShell 中常静默失败
• 执行耗时不可控：1000 次提交的仓库，简单删文件操作也常超 5 分钟；若含二进制文件，内存占用飙升，进程易被系统 kill
• Git 官方已在 2.22+ 版本中将 git filter-branch 标记为 deprecated，文档明确推荐 git-filter-repo 或 BFG

BFG 清理单个分支的正确姿势

BFG 本身不支持“只处理某一分支”，它的设计前提就是操作完整镜像仓库（--mirror 克隆）。但你可以通过镜像 + 引用过滤，安全实现“事实上的分支级清理”：

• 先用 git clone --mirror 创建裸仓库副本，确保包含全部分支、tags 和 reflog
• 运行 BFG 命令时，**不指定分支名**，让它扫描全量历史；BFG 默认保留 HEAD 所指提交的文件内容（即你当前检出分支的最新快照），只清理历史中的 blob
• 清理后，用 git push --force --all 和 git push --force --tags 同步到远端 —— 这会重写所有分支，但协作方只需重新克隆或重置本地分支，不会丢失新提交
• 若只想影响特定分支（如仅清理 feature/upload 的历史），需在镜像仓库中先 git update-ref -d refs/heads/main 等非目标分支引用，再运行 BFG，最后只推回目标分支：git push --force origin feature/upload

清理后必须做的三件事，缺一不可

BFG 只删除 blob 引用，不触发物理回收。不执行以下操作，.git/objects 体积几乎不变：

• 进入清理后的裸仓库目录，运行：git reflog expire --expire=now --all（清除所有 reflog 条目，否则旧对象仍被引用）
• 紧接着运行：git gc --prune=now --aggressive（强制垃圾回收，真正删掉未被任何 commit/tree/tag 引用的对象）
• 验证是否生效：用 git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print $3, $4}' | sort -n | tail -5 查看剩余最大 blob 尺寸 —— 若仍存在 >50MB 的文件，说明 GC 未成功或 BFG 参数未命中目标

容易被忽略的 Java 版本陷阱

BFG 是 Scala 编译的 jar，对 JVM 兼容性敏感。实测发现：

• Java 17+ 在 macOS 上常报 UnsupportedClassVersionError，因 BFG 发布包默认编译目标为 Java 8
• Windows 上若装了多个 JDK，java -version 显示 11，但 javaw.exe 可能调用旧版 JRE，导致 BFG 启动失败却无明确错误
• 最稳方案：显式指定运行时，例如：/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -jar bfg-1.14.0.jar --strip-blobs-bigger-than 20M my-repo.git