密钥误提交到 Git 后，为什么应先撤销再清理历史

发现令牌出现在提交记录后，删除当前文件或把仓库改成私有，并不能让已经复制出去的凭证失效。第一目标应是缩短它仍可被使用的时间。

先让旧凭证失去作用

GitHub 官方文档建议，对泄露的秘密首先撤销或轮换。清理历史会影响提交哈希、协作分支和已有副本，因此不应抢在凭证处置之前盲目执行。

由凭证所属系统的负责人确认它的权限、环境与依赖服务，在可控的切换流程中签发替代凭证、更新使用方并撤销旧值。不要在工单、群聊或截图中再次复制完整秘密；使用名称、指纹或末尾少量字符进行内部定位即可。

调查范围比删文件更重要

• 记录首次进入仓库的时间、仓库可见范围及可能的分叉、克隆、构建产物和日志副本。
• 检查凭证在暴露窗口内的使用日志，寻找异常来源、操作与权限变化。
• 确认替代凭证只具有必要权限，并验证所有合法依赖恢复工作。
• 检查同一配置文件中是否还有关联秘密需要处理。

再决定如何清理仓库

按托管平台的官方流程协调历史重写与副本清理，提前通知协作者处理分支、缓存及引用。不能承诺远程历史清理会删除所有人已经获得的副本，也不要在不了解范围时对所有分支强制覆盖。

完成后用旧凭证执行经批准的无害验证，确认它已无法访问；用新配置运行必要的健康检查。报告记录失效时间、受影响系统、异常调查结果与遗留风险，避免仅写“代码已删除”。

预防复发可结合秘密管理服务、提交前检查和平台推送保护。示例配置应使用占位值，开发与生产凭证分开管理。

参考：GitHub：Removing sensitive data from a repository。核对日期：2026年10月4日。