密钥字符串推进了公开仓库：先吊销，再谈改写历史的真实含义

自己捣鼓过钱包脚本、交易机器人或者数据管道的开发者，几乎都做过同一个噩梦：一个带着私钥、接口密钥或者数据库密码的配置文件，混进某次提交，被推到了公开仓库。这篇文章给一份三十分钟内能跑完的顺序，讲清楚为什么第一步是吊销、为什么删掉文件重新推送不算修复，以及怎么让它不再发生。机制部分以 GitHub 官方文档的说法为准，不构成投资建议。

先理解一个事实：公开仓库的提交历史会被无限复制。你推送的同时，爬虫、镜像服务、随手 fork 的人都在读。GitHub 自己的文档写得很明白——如果你只改写历史再强推，带敏感数据的旧提交仍可能留在别人的克隆和 fork 里，仍然可以通过提交哈希直接访问，还会留在已关闭的拉取请求差异视图中。更现实的时间线是：针对公开仓库的自动化扫描是分钟级的，密钥从曝光那一刻起就应当视为已经泄露。所以正确顺序的第一步永远是吊销：在密钥的来源系统——交易所接口控制台、云服务商、签名服务——把它立即禁用或更换。官方文档也明确说，密钥一旦吊销轮换、不再可用，改写历史这一步可能根本不必做。优先级是：吊销、排查、清理，不要倒过来。

具体四步。第一步，立即吊销并轮换密钥；如果是钱包私钥，不要抱任何侥幸，把该钱包视为完全失陷，用新生成的助记词开新地址，按先迁移后断舍的顺序转移资产，之后不再使用旧地址。第二步，排查暴露窗口：吊销前的这段时间里，交易所接口的调用日志、云服务的审计日志、链上地址的动账记录，逐条看有无异常，这是你判断损失范围的全部依据。第三步，才决定要不要改写历史：密钥已吊销且仓库公开的情况下，很多场景从最新版本里删掉文件就够了；只有要求彻底消除文本残留时，才值得用 git-filter-repo 这类工具重写历史，而官方文档列清了代价——提交签名会失效、分支保护要临时解除、协作者必须重新克隆，任何一个还留着旧克隆的人随手一次普通拉取再推送，就能把敏感数据原样带回仓库。第四步，通知协作者丢弃旧克隆重新拉取，合并或关闭在途的拉取请求，避免清理期间被新提交覆盖。

预防环节里有一项常被误解的防线：GitHub 提供推送保护，检测到受支持的密钥格式进入公开仓库时会直接阻止推送，个人用户的账号默认对公开仓库开启。但注意”受支持的格式”是有范围的——它面向常见平台令牌，不等于认识你的钱包私钥和助记词，不要把默认防线当万能保险。更可靠的习惯有四条：所有密钥一律不进仓库，统一放环境变量或密钥管理服务；把 env 类文件名加进忽略清单，并用 git check-ignore 验证规则真的生效；新仓库首次公开前跑一次泄露扫描器，历史仓库补扫一遍；参与多仓库协同时固定使用扫描流程，不靠记性。

最后给两条心态校准。第一，不要假设仓库小、没人看——收割是自动化、无差别的，扫公开提交的不挑对象。第二，也不要在事发后恐慌到删库注销账号，那会毁掉你自己排查用的现场。事发时的正确姿势就是上面四条：先吊销，用日志划清暴露窗口，按需要清理，把防线装进流程。还有一条边界必须说透：如果暴露的是钱包私钥，历史改写做得再干净，泄露这件事本身也不能逆转——资产迁移和地址弃用才是处置本身，其余都只是卫生工作。