git filter-repo 是当前最可靠的历史清理工具，Git 官方已弃用 git filter-branch，GitHub 和 GitLab 均推荐其用于敏感文件清除，因其更快、更安全且避免 shell 环境差异导致的执行失败。
git filter-repo 是当前最可靠的历史清理工具
Git 官方已弃用 git filter-branch，GitHub 和 GitLab 都明确推荐用 git filter-repo 处理敏感文件清除。它更快、更安全，不会因 shell 环境差异导致命令执行失败（git filter-branch 在 macOS 或 Windows Git Bash 下常因引号/转义出错）。
- 必须先安装：
pip install git-filter-repo（注意不是git-filter-repo包名旧版） - 清除单个文件（如
secrets.txt）：git filter-repo --path secrets.txt --invert-paths --force - 清除整个目录（如
config/dev/）：git filter-repo --path config/dev/ --invert-paths --force - 如果提示
filter-repo not found，检查 Python 脚本是否在$PATH中；Mac 用户可能需运行hash -d git-filter-repo刷新命令缓存
强制推送前必须全员同步协作状态
清除历史 ≠ 清除风险。一旦执行 git push --force --all，所有协作者的本地分支将与远程不兼容——他们的 git pull 会失败，git rebase 可能重演已删除的敏感提交。
- 不能只发个群消息“大家拉新仓库”，要确认每人执行：
git clone https://github.com/your/repo.git new-repo（而非git pull --rebase） - CI/CD 流水线、部署脚本、Docker 构建上下文里若有旧克隆副本，也会继续读取被删文件的缓存对象
- GitHub 上建议临时开启
Branch protection rules → Require force pushes to be approved，避免误操作覆盖他人正在调试的修复分支
.git-credentials 不是源头，但会掩盖问题
很多人发现“删了密钥文件，为什么 git push 还不弹密码？”——其实是凭据管理器仍在自动填充旧 token 或密码。这不是 Git 历史问题，而是本地认证层干扰判断。
- 先查当前生效的凭据助手：
git config --get credential.helper（常见值为store、osxkeychain、manager-core） - 清空凭据文件（Linux/macOS）：
rm ~/.git-credentials；Windows 用户需进凭据管理器删 “git:https://github.com” 条目 - 若想彻底禁用自动保存：
git config --global --unset credential.helper（之后每次 push 都会手动输，适合高敏环境） - 注意：
credential.helper = store时，即使删了.git-credentials，下一次输入仍会立刻写回——必须先 unset helper
删完不等于安全，轮换密钥才是关键动作
Git 历史清理只是让代码仓库“看起来干净”，但所有曾被提交过的密钥，只要有人 clone 过旧版本、或 GitHub 的 secret scanning 报过警、甚至搜索引擎缓存过 raw 文件链接，就已实质泄露。
- 立即撤销所有已泄露的凭据：GitHub PAT 在
Settings → Developer settings → Personal access tokens撤销；云平台 API Key 必须登录控制台手动 disable - 不要依赖“删了就没人知道”——Git 对象在 reflog、stash、未 push 的本地分支、IDE 本地历史中都可能残留；
git gc --prune=now --aggressive只影响当前仓库，不影响他人机器 - 真正防住下一次？加
.gitignore不够，要用 pre-commit hook 扫描secret|token|key|password正则，或者上git-crypt加密敏感文件本身
历史清理不是单点操作，而是一条链：识别 → 清理 → 强推 → 通知 → 撤销 → 轮换 → 预防。漏掉任意一环，密钥就还在野。
