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
