发现密钥泄露后，第一步永远是立即作废密钥，然后再考虑清理 Git 历史记录，因为修改历史无法阻止已泄露密钥被滥用。
先说结论：清理历史是亡羊补牢，失效密钥才是止损关键，推荐使用 git-filter-repo 工具重写历史。
- 先判断：确认泄露范围是单个文件还是特定字符串，评估是否涉及协作分支。
- 优先做：在云服务商或内部系统立即轮换（Rotate）受影响的密钥，使其失效。
- 再验证：清理后强制推送，并通知所有协作者重新克隆仓库。
前置检查与环境准备
git-filter-repo 默认要求仓库是新鲜克隆（fresh clone），即没有额外的 remote 配置。如果是在现有仓库操作，需添加 `--force` 参数或确保环境干净。
1. 检查仓库状态
git remote -v如果存在多个 remote 或非预期配置，建议先克隆一份新副本进行操作。
2. 安装工具
Git 官方不再推荐 git filter-branch。安装 git-filter-repo 时注意权限问题：
pip install `--user` git-filter-repo若遇到权限报错，可尝试添加 sudo 或检查 Python 环境路径。
实操步骤：清理敏感信息
1. 立即失效密钥
在操作 Git 之前，先去对应的服务平台（如 AWS 控制台、数据库权限页）删除或轮换密钥。这是防止损失扩大的唯一有效手段。
2. 备份仓库（重要）
重写历史是破坏性操作，必须在本地保留一份原始仓库的完整备份，以便操作失误时回滚。
cp -r your-repo your-repo-backup3. 执行清理
根据泄露类型选择命令。清理完成后，本地历史哈希值会发生变化。
清理特定文件：
git filter-repo `--invert-paths` `--path` 敏感文件名.txt清理特定字符串（如密钥内容），需创建替换文件：
echo '旧密钥==>REDACTED' > replacements.txt
git filter-repo `--replace-text` replacements.txt若提示仓库非新鲜克隆，可添加 `--force` 参数强制运行。
安全推送策略
清理完成后，需将更改同步到远程仓库。为避免覆盖他人提交，建议使用 `--force-with-lease` 而非 `--force`，并指定分支名。
git push origin `--force-with-lease` <分支名>谨慎使用 `--all` 参数，除非你确认所有分支都需要重写且无其他人正在开发。
怎么验证是否生效
清理完成后，可以使用 git log 配合搜索参数检查历史中是否还包含敏感信息：
git log -S "敏感密钥片段" `--all`如果没有输出，说明历史记录中已无该字符串。同时检查远程仓库网页版的历史记录，确认旧提交已消失。
操作失败如何回滚
如果清理后发现误删了重要提交，可利用之前备份的仓库恢复：
rm -rf your-repo
cp -r your-repo-backup your-repo
cd your-repo恢复后重新评估清理方案，避免再次误操作。
常见坑
1. 忽略其他分支：只清理了 main 分支，但泄露提交存在于 feature 分支中，需确保处理所有相关引用。
2. CI/CD 缓存：某些持续集成系统会缓存代码副本，清理 Git 后需检查 CI 日志是否仍暴露密钥。
3. 浅克隆用户：部分协作者可能使用 shallow clone，强制推送后他们可能无法同步，需沟通重新克隆。
4. 密钥已扩散：如果仓库是公开的，密钥可能已被爬虫抓取，此时仅清理 Git 不够，必须确保密钥已作废。
参考来源
- GitHub Docs: Removing sensitive data from a repository (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)
- git-filter-repo Documentation (https://github.com/newren/git-filter-repo)