代码仓库最好从第一天就开源，并且意识到代码是开源的，从而绝对不去在代码里提交一些密码信息，强迫自己养成好习惯。不将密码信息明文保存在代码里，有一些挑战。因为安全原因，系统总免不了需要通过一些密码信息才能够访问某些服务，比如连接数据库等等。
这些挑战其实有很多应对措施，比如写代码在运行时通过环境变量获取密码信息，在部署时将环境变量注入到具体的环境，从而代码和密码就解耦了。如果通过 GitHub Actions 进行部署，那么可以将密码设置在 GitHub Actions Secerts 中：
当然，还可以用 SOPS 等方案，通过将密文加密后存储在代码库中，如《加密 Kubernetes 集群中的敏感信息 - Jeff Tian的文章 - 知乎 》和《Pulumi 惊艳到我了（还可以无限免费薅 AI 羊毛） - Jeff Tian的文章 - 知乎 》提到的。
虽然但是，各种原因导致某一天你需要开源一个历史悠久的代码仓库时，发现代码里有一些硬编码的密码信息，不免有些一筹莫展。因为即使通过后续提交移除了这些密码信息，但是仍然可以通过历史查看到这些明文密码，尽管可以通过将历史全部清空来避免开源时泄露密码，但你不愿意这样做，希望能够保留住历史。
不用愁，篡改 git 历史的艺术帮你解决烦恼！
其实我不是第一次做这种篡改 git 历史的事情了，之前做过一次代码迁移的工作，需要只迁移部分目录，但又要保持所有的历史记录，详见《部分迁移代码库时保留完整的提交历史 - Jeff Tian的文章 - 知乎 》。
今天再来一场篡改 git 历史的大戏。
BFG
和上次使用 <font style=color:rgb(25, 27, 31);background-color:rgb(248, 248, 250);>git-filter-repo<font style=color:rgb(25, 27, 31);background-color:rgb(248, 248, 250);> 不同，今天使用 BFG。
<font style=color:rgb(25, 27, 31);background-color:rgb(248, 248, 250);>这个开源工具的源代码在这里： https://github.com/rtyley/bfg-repo-cleaner，在 Mac 中可以通过 brew install bfg来安装它。
假设有一个文件中曾经出现过明文密码，首先，确保最新代码中已经是移除了密码信息的状态了，这时通过查看该文件的历史，可以看到有很多行，并且可以通过之前的历史看到明文密码。
然后执行 bfg --delete-files PATH_TO_FILE（注意是文件名，不是文件路径名哦），很快就会看到已经执行完毕。尽管 git status 显示仓库中没有任何改动，然而通过再次查看那个文件的历史，就会发现它只有一个提交了，感觉是全新创建的一样，并且是最新的不带明文密码的版本。
这时强制推送到远端即可，然后再将仓库开源，这时就像从来没有往代码库里提交过明文密码的效果一样了。