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 openjdk8 export JAVA_HOME/usr/local/opt/openjdk8然后下载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 bfgjava -jar ~/bin/bfg-1.14.0.jar2.2 克隆仓库的正确姿势关键的一步是用--mirror方式克隆仓库这相当于创建了一个完整的镜像副本。去年我带实习生时他直接用了普通clone结果BFG完全不起作用。正确的做法是git clone --mirror gitgithub.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.txtDB_PASSWORD123456 DB_PASSWORD****** regex:API_KEY\w API_KEYREMOVED然后执行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 --expirenow --all git gc --prunenow --aggressive最后强制推送到远程git push --force但可能会遇到分支保护的问题。我们团队的解决方案是临时关闭分支保护创建备份分支执行强制推送立即重新启用保护记得通知所有团队成员重新克隆仓库否则他们的本地副本会持续报错。有次我们清理后忘了通知结果前端工程师花了半天排查为什么他的git操作总是失败。5. 避坑指南血泪教训总结第一次使用时我差点酿成事故——没有备份就直接操作。现在我的checklist是完整备份仓库在测试分支验证效果选择非工作时间操作提前通知团队暂停提交另一个常见问题是处理Windows换行符。建议在replace.txt中加入regex:\r(\n) $1对于包含特殊字符的替换记得用反斜杠转义。有次替换URL中的参数时问号没转义导致正则匹配失效。最惊险的一次是处理子公司合并的仓库BFG运行中途OOM崩溃导致仓库损坏。现在对于超过10GB的仓库我会先按目录分批处理。JVM参数也可以调整java -Xmx4g -jar bfg.jar [options] repo.git6. 进阶技巧当简单清理不够用时对于复杂的替换需求可以组合多个条件。上周我需要保留近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 done7. 预防胜于治疗建立代码卫生习惯自从那次密钥泄露事件后我们团队现在使用pre-commit钩子自动扫描敏感信息配置.gitignore模板大文件用Git LFS管理每月例行仓库体检最有效的还是培养开发者的安全意识。我制作了常见陷阱清单新人入职必须通过测试。比如永远不要提交包含真实数据的配置文件测试用的密钥必须用环境变量超过10MB的文件必须特别审批有次代码审查时发现有人提交了内网IP立即用BFG清理并作为案例分享。这种实战教学比单纯讲规则有效得多。
告别历史包袱：使用 Git BFG 高效清理仓库敏感数据与冗余文件
发布时间：2026/6/11 11:12:17
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 openjdk8 export JAVA_HOME/usr/local/opt/openjdk8然后下载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 bfgjava -jar ~/bin/bfg-1.14.0.jar2.2 克隆仓库的正确姿势关键的一步是用--mirror方式克隆仓库这相当于创建了一个完整的镜像副本。去年我带实习生时他直接用了普通clone结果BFG完全不起作用。正确的做法是git clone --mirror gitgithub.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.txtDB_PASSWORD123456 DB_PASSWORD****** regex:API_KEY\w API_KEYREMOVED然后执行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 --expirenow --all git gc --prunenow --aggressive最后强制推送到远程git push --force但可能会遇到分支保护的问题。我们团队的解决方案是临时关闭分支保护创建备份分支执行强制推送立即重新启用保护记得通知所有团队成员重新克隆仓库否则他们的本地副本会持续报错。有次我们清理后忘了通知结果前端工程师花了半天排查为什么他的git操作总是失败。5. 避坑指南血泪教训总结第一次使用时我差点酿成事故——没有备份就直接操作。现在我的checklist是完整备份仓库在测试分支验证效果选择非工作时间操作提前通知团队暂停提交另一个常见问题是处理Windows换行符。建议在replace.txt中加入regex:\r(\n) $1对于包含特殊字符的替换记得用反斜杠转义。有次替换URL中的参数时问号没转义导致正则匹配失效。最惊险的一次是处理子公司合并的仓库BFG运行中途OOM崩溃导致仓库损坏。现在对于超过10GB的仓库我会先按目录分批处理。JVM参数也可以调整java -Xmx4g -jar bfg.jar [options] repo.git6. 进阶技巧当简单清理不够用时对于复杂的替换需求可以组合多个条件。上周我需要保留近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 done7. 预防胜于治疗建立代码卫生习惯自从那次密钥泄露事件后我们团队现在使用pre-commit钩子自动扫描敏感信息配置.gitignore模板大文件用Git LFS管理每月例行仓库体检最有效的还是培养开发者的安全意识。我制作了常见陷阱清单新人入职必须通过测试。比如永远不要提交包含真实数据的配置文件测试用的密钥必须用环境变量超过10MB的文件必须特别审批有次代码审查时发现有人提交了内网IP立即用BFG清理并作为案例分享。这种实战教学比单纯讲规则有效得多。
