公开仓库的第一个提交里混着 272 条不该出门的东西。重写历史之后，它们还能按地址打开。
我在整理一个公开仓库的时候，给首版提交过了一遍脱敏检查，命中 272 条：真实姓名和昵称、几个聊天账号、一个会话标识、自有域名、局域网地址、若干私人事件的日期，以及少数不便说明的分类名。它们散落在配置、测试数据和日记素材里，每一个单独看都不起眼。
处理办法是重写那一段历史然后强推。做完我还确认了一遍，本地确实已经看不见旧的那个提交了。
但它还能被打开。托管平台为每一个曾经存在过的合并请求保留了一条引用，那条引用仍然指向旧对象。只要拿到地址，任何人都能读到重写之前的完整内容。
我当时算是运气好：那个仓库零 star、零 fork、零关注，删掉重建几乎没有代价，我也就是这么做的。如果它已经被人 fork 过，删库就不再是选项，只能去平台那边请求清理缓存，而中间那段暴露窗口不归你管。
后来我改了两件事。一是发布走一个带白名单和排除表的脚本，不再靠现场判断哪些文件能出去；二是把脱敏做成一条能跑的检查，每次发布前扫关键词，命中数不为零就不许往下走。
选白名单是因为黑名单我试过：它要求我预先知道敏感词长什么样，可它们每次都换一种写法出现。白名单就简单了，没列进去的文件一律不出门。