告别历史包袱：使用 Git BFG 高效清理仓库敏感数据与冗余文件

1. 为什么你的Git仓库需要"瘦身手术"？

每次提交代码就像往仓库里扔东西，时间久了难免会混进一些"垃圾"——可能是临时测试用的超大视频文件，也可能是忘记删除的配置文件里的数据库密码。更糟的是，这些"垃圾"会永远留在提交历史里，就像相册里不小心拍到的尴尬照片，删都删不掉。

我去年就遇到过这样的尴尬：团队新人把包含AWS密钥的配置文件推送到远程仓库，虽然发现后立即删除了文件，但密钥已经躺在历史记录里。用常规方法要重写整个仓库历史，相当于把房子拆了重建。直到发现BFG这个神器，才用10分钟就干净地抹除了所有历史记录中的密钥，而且保留了其他正常提交。

传统做法是用git-filter-branch，但它的操作复杂得让人头疼。就像用瑞士军刀做开颅手术，不仅慢（处理大型仓库可能要几天），还容易出错。BFG则是专门为这个场景设计的"激光手术刀"，用Scala编写，官方测试显示速度能快720倍。实际使用中，我清理过一个3GB的仓库，git-filter-branch跑了2小时还没完，BFG只用了3分钟。

2. 快速上手指南：从安装到第一次清理

2.1 准备工作就像组装手术工具包

首先确保你的系统有Java环境（BFG是用Scala写的）。我在Mac上测试时发现，即使装了Java 17也会报错，换成Java 8就正常了。如果遇到类似问题，可以试试：

brew install openjdk@8 export JAVA_HOME=/usr/local/opt/openjdk@8

然后下载BFG的jar包，建议直接到官网获取最新版。我习惯在~/bin目录下存放这类工具：

mkdir -p ~/bin && cd ~/bin wget https://repo1.maven.org/maven2/com/madgag/bfg/1.14.0/bfg-1.14.0.jar alias bfg="java -jar ~/bin/bfg-1.14.0.jar"

2.2 克隆仓库的正确姿势

关键的一步是用--mirror方式克隆仓库，这相当于创建了一个完整的镜像副本。去年我带实习生时，他直接用了普通clone，结果BFG完全不起作用。正确的做法是：

git clone --mirror git@github.com:your/repo.git cd repo.git

注意这里生成的repo.git是个裸仓库，没有工作目录。我第一次用时还以为操作失败了，其实这是正常现象。

3. 实战演练：三种常见清理场景

3.1 删除误提交的大文件

上周我们团队的设计师不小心提交了200MB的PSD源文件，导致所有人pull时都卡住。用这个命令瞬间解决：

bfg --strip-blobs-bigger-than 50M repo.git

参数里的50M是阈值，所有超过这个大小的二进制文件都会被清理。建议先从保守值开始，比如先处理100M以上的文件，再逐步降低阈值。有次我直接设为1M，结果把项目里的字体文件也删了，不得不重新配置。

3.2 彻底抹除敏感信息

对于配置文件中的密码、密钥，需要创建替换规则文件replace.txt：

DB_PASSWORD=123456 ==> DB_PASSWORD=****** regex:API_KEY=\w+ ==> API_KEY=REMOVED

然后执行：

bfg --replace-text replace.txt repo.git

这里有个坑：BFG默认会保护最新的commit，如果敏感信息恰好在最近提交，需要加--no-blob-protection参数。去年审计时发现这个问题，差点以为工具失效了。

3.3 批量删除特定文件/目录

比如要删除所有临时文件*.tmp和test_data目录：

bfg --delete-files '*.tmp' repo.git bfg --delete-folders test_data repo.git

注意这里的模式匹配是全局的，我曾在子项目里有重要的tmp目录，结果被误删。现在会先用--dry-run参数测试，确认无误再实际执行。

4. 术后护理：让清理真正生效

执行完BFG后，仓库就像刚做完手术的病人，需要"康复治疗"：

cd repo.git git reflog expire --expire=now --all git gc --prune=now --aggressive

最后强制推送到远程：

git push --force

但可能会遇到分支保护的问题。我们团队的解决方案是：

1. 临时关闭分支保护
2. 创建备份分支
3. 执行强制推送
4. 立即重新启用保护

记得通知所有团队成员重新克隆仓库，否则他们的本地副本会持续报错。有次我们清理后忘了通知，结果前端工程师花了半天排查为什么他的git操作总是失败。

5. 避坑指南：血泪教训总结

第一次使用时，我差点酿成事故——没有备份就直接操作。现在我的checklist是：

1. 完整备份仓库
2. 在测试分支验证效果
3. 选择非工作时间操作
4. 提前通知团队暂停提交

另一个常见问题是处理Windows换行符。建议在replace.txt中加入：

regex:\r(\n) ==> $1

对于包含特殊字符的替换，记得用反斜杠转义。有次替换URL中的参数时，问号没转义导致正则匹配失效。

最惊险的一次是处理子公司合并的仓库，BFG运行中途OOM崩溃，导致仓库损坏。现在对于超过10GB的仓库，我会先按目录分批处理。JVM参数也可以调整：

java -Xmx4g -jar bfg.jar [options] repo.git

6. 进阶技巧：当简单清理不够用时

对于复杂的替换需求，可以组合多个条件。上周我需要：

• 保留近3个月的提交记录
• 只处理src目录下的文件
• 但排除test目录

最终方案是先克隆仓库，用git filter-repo预处理，再用BFG精细清理。虽然步骤多了，但安全性更高。

监控方面，我写了个pre-receive钩子脚本，当检测到敏感信息时自动拒绝推送。配合BFG定期扫描，形成双重防护。关键部分是：

#!/bin/bash while read oldrev newrev refname; do if git diff --name-only $oldrev $newrev | xargs grep -n 'API_KEY'; then echo "ERROR: Commit contains sensitive data" exit 1 fi done

7. 预防胜于治疗：建立代码卫生习惯

自从那次密钥泄露事件后，我们团队现在：

• 使用pre-commit钩子自动扫描敏感信息
• 配置.gitignore模板
• 大文件用Git LFS管理
• 每月例行仓库体检

最有效的还是培养开发者的安全意识。我制作了常见陷阱清单，新人入职必须通过测试。比如：

• 永远不要提交包含真实数据的配置文件
• 测试用的密钥必须用环境变量
• 超过10MB的文件必须特别审批

有次代码审查时发现有人提交了内网IP，立即用BFG清理并作为案例分享。这种实战教学比单纯讲规则有效得多。