一、那次惊心动魄的下午
事情发生在某周三下午。当时我们正在紧急上线一个小需求。
新入职的同事小 A 负责一个 Node.js 服务的配置。为了本地测试方便，他在项目根目录创建了一个 .env 文件，里面填入了测试环境的数据库密码和 OSS 密钥。
就在他执行 git add . && git commit -m "feat: add config" 并推送到仓库后不到 5 分钟，安全部的同事就直接敲响了我们组长的门。
原因很简单： 公司内部的安全扫描系统自动识别出了代码中包含类似 AK/SK 的模式，并立即触发了告警。
二、问题出在哪？
小 A 觉得很委屈：「虽然我提交了，但这是公司内部的私有 Git 仓库，外面的人看不到啊。」
但这正是最大的隐患：
- 权限扩散：私有仓库对公司所有有权限的开发者开放。如果这些密钥被恶意使用，后果不堪设想。
- 审计风险：一旦密钥进入 Git 历史记录，即便你后续删除了文件，它依然存在于历史 commit 中。
- CI/CD 风险：构建服务器可能会无意中将这些敏感文件打包进镜像或部署环境。
三、如何补救？
如果你已经不小心提交了敏感文件，简单的 git rm 是不够的。你需要：
1. 彻底从历史中抹除
使用 git filter-branch 或更好的工具 bfg-repo-cleaner。
# 例子：从历史中删除 .env
bfg --delete-files .env
2. 立即更换密钥
这是最重要的一步！即便你删除了代码，也要假设密钥已经泄露，必须立即在服务端重置或轮换所有受影响的密钥。
四、.gitignore 的最佳实践
为了避免这种情况再次发生，建议每个项目都遵循以下原则：
- 预置模板：使用
githooks或项目脚手架，在初始化时就强制生成.gitignore。 - 环境隔离：只提交
.env.example（仅包含键名，不包含具体值），具体的.env由本地环境或 CI/CD 环境变量注入。 - 全局忽略：在你的电脑上设置全局
.gitignore_global，忽略如.DS_Store、.vscode等个人编辑器文件。
五、总结
安全无小事。一个小的 .gitignore 疏忽，可能导致巨大的安全漏洞或昂贵的清理成本。
你是否也遇到过类似的「惊险时刻」？欢迎在评论区分享你的踩坑经历！
