最近琢磨着把之前做的一个小项目彻底开源出去，顺便也想把自己平时的一些实践经验整理成文档分享给大家。结果在整理代码的时候，突然发现一些配置信息里头，竟然不小心把一些敏感的内部测试接口地址和密钥给硬编码进去了。
当时就一个激灵，虽然知道这些测试环境的密钥就算泄露了影响也不会太大，毕竟不是生产环境的，但心里还是有点不舒服，毕竟涉及到“泄露”这俩字，听着就让人头疼。
发现问题，赶紧止损
我的第一反应是赶紧把代码库设成私有。那个项目是用Git管理的，代码已经推到GitHub上了。虽然之前就设成了私有库，但为了开源，我正准备转成公开库。幸好还没点那个“公开”按钮，不然麻烦就大了。
我马上停下手头所有工作，把代码库里所有包含敏感信息的配置文件，特别是那个测试用的API密钥和几个内部的测试URL，全部都做了标记。
清理历史记录是关键
接下来就是最头疼的一步——清理Git历史记录。我知道Git的强大之处在于它的历史追溯能力，但这回这份能力成了我的心腹大患。如果不把包含敏感信息的那个提交记录从历史里彻底抹掉，那只要有人克隆整个仓库，还是能翻出那些“老黄历”。
我之前听说过git filter-branch这个命令，专门用来重写历史的，但那玩意儿太复杂，而且万一操作失误，整个仓库的历史就乱套了。我决定找一个更简单，更安全的方法。
- 找到泄露文件的哈希值： 我先用
git log --pretty=oneline -- path/to/leaked/file找到包含敏感信息的那个提交记录的哈希值。 - 使用BFG Repo-Cleaner： 听说这个工具比
filter-branch快得多，而且操作更傻瓜化。我直接下载了BFG的jar包，然后运行命令：java -jar * --delete-files * *。这里就是我那个包含密钥的文件名。
这个BFG工具牛，跑起来嗖嗖的，它快速地遍历了整个Git历史，把所有叫这个名字的文件都给彻底删除了。删完之后，历史记录就变了，那些泄露的文件就像从来没存在过一样。
一步：强制推送
历史记录重写之后，本地仓库和GitHub上的远程仓库的历史就不一样了。为了让远程仓库也干净起来，我必须进行强制推送。
git push --force
这个命令很危险，因为它会覆盖远程仓库的历史。但在这个场景下，这是必须做的。我深吸一口气，敲下回车键。推送成功后，我再次检查了GitHub上的代码，历史记录里那个包含敏感信息的提交果然找不到了。
总结与反思：怎么预防下次？
处理完这些烂摊子，我坐下来好好反思了一下。这回虽然是测试环境的密钥，影响不大，但下次要是生产环境的密钥泄露了，那可真是要出大麻烦的。
我总结了两个以后必须坚持的习惯：
- 永远不要提交敏感信息： 密钥、证书、接口URL，这些东西绝对不能直接写在代码文件里然后提交到Git。
- 使用环境变量或专门的配置文件： 应该用类似
.env文件或者系统的环境变量来存这些信息，并且一定要把这个.env文件加入到.gitignore里，从源头上杜绝提交的可能性。
我还专门去学习了一下Git的.gitignore配置，确保下次任何配置文件，尤其是那种包含私密数据的，一律在提交前就被忽略掉。虽然这回只是虚惊一场，但总算是把“泄露隐私信息后如何自救”这套流程跑了一遍，感觉心里踏实多了。分享出来，大家以后遇到类似情况也能有个参考，关键时刻别慌。
还没有评论，来说两句吧...