安全习惯

这一课你将能做到

1. 正确配置 .gitignore 并理解其作用范围
2. 使用环境变量或配置管理工具处理敏感信息，而非硬编码
3. 如果意外提交了密钥，能够使用 git filter-repo 或 BFG Repo-Cleaner 彻底清除历史记录

为什么要学

代码仓库不是保险箱。Git 的设计初衷是「永久保存历史」，这意味着一旦你提交了敏感信息（如 API 密钥、数据库密码、私钥），它就会永远留在历史记录中，即使你后来删掉了文件，别人依然可以通过查看历史提交找到它。这可能导致你的云服务器被滥用、数据库被拖库、公司机密泄露，后果可能是灾难性的。

先建立图像

把 Git 仓库想象成一个公开的相册。你把一张照片（包含敏感信息的文件）贴进去，又撕下来（删除文件），但相册的每一页（提交历史）都留下了印记。任何拿到相册（克隆仓库）的人，只要翻到那一页，就能看到照片。

工作区 (包含敏感信息) → 暂存区 → 提交 → 远程仓库 (GitHub)
   ↑                                              ↓
   └────────────── 他人克隆/拉取 ──────────────────┘

跟着做

步骤 1：创建并配置 .gitignore

.gitignore 文件告诉 Git 哪些文件或目录不需要跟踪。

1. 在项目根目录创建 .gitignore 文件：

   touch .gitignore
   

2. 添加规则，例如：

   # 依赖目录
   node_modules/
   vendor/
   
   # 日志文件
   *.log
   
   # 环境变量文件
   .env
   .env.local
   
   # IDE 配置文件
   .idea/
   .vscode/
   
   # 编译产物
   target/
   dist/
   

3. 提交 .gitignore 文件本身，让团队所有成员共享规则。

步骤 2：使用环境变量管理敏感信息

绝对不要把密码、密钥硬编码在代码里。

错误示范：

// src/main/java/com/example/DatabaseConfig.java
public class DatabaseConfig {
    private static final String DB_PASSWORD = "my-secret-password-123";
}

正确示范：

// src/main/java/com/example/DatabaseConfig.java
public class DatabaseConfig {
    private static final String DB_PASSWORD = System.getenv("DB_PASSWORD");
}

然后在运行项目前，通过命令行设置环境变量：

# Linux/macOS
export DB_PASSWORD="my-secret-password-123"

# Windows (PowerShell)
$env:DB_PASSWORD="my-secret-password-123"

步骤 3：处理已提交的敏感信息

如果你发现自己已经把 .env 文件提交到了远程仓库，必须立即采取行动。

1. 从当前代码中删除文件：

   rm .env
   git rm --cached .env
   git commit -m "security: 删除包含敏感信息的 .env 文件"
   

2. 修改密码/密钥：立即登录相关服务（如 AWS、数据库控制台），修改所有泄露的凭证。旧密码已经不安全了。

3. 从历史中彻底删除文件（使用 BFG Repo-Cleaner，比 git filter-branch 更快更安全）：

   # 下载 bfg.jar
   wget https://repo1.maven.org/maven2/com/madgag/bfg/1.14.0/bfg-1.14.0.jar
   
   # 克隆一个镜像仓库
   git clone --mirror git@github.com:your-username/your-repo.git
   
   # 运行 BFG 删除 .env 文件
   java -jar bfg.jar --delete-files .env your-repo.git
   
   # 清理并推送
   cd your-repo.git
   git reflog expire --expire=now --all && git gc --prune=now --aggressive
   git push --force
   

4. 通知团队成员：告诉他们你已经强制推送了新的历史记录，他们需要重新克隆仓库或执行 git pull --rebase。

讲清楚要点

1. 预防胜于治疗：在提交前养成检查 git status 和 git diff 的习惯，确保没有敏感文件被加入暂存区。
2. .gitignore 不是万能的：它只对未跟踪的文件有效。如果文件已经被提交过，即使加入 .gitignore 也不会被忽略，必须先使用 git rm --cached 将其从索引中移除。
3. 环境变量是标准做法：几乎所有现代编程语言和部署平台（如 Docker, Kubernetes, Heroku）都支持环境变量，这是管理配置的黄金标准。
4. 历史记录是公开的：一旦推送到 GitHub（即使是私有仓库），就认为它已经泄露。GitHub 的爬虫会扫描公开仓库中的密钥格式。
5. 使用密钥管理服务：对于生产环境，考虑使用专业的密钥管理服务（如 AWS KMS, HashiCorp Vault, Azure Key Vault），而不是手动管理环境变量。

你可能会懵的地方

• 我只是提交到了一个私有仓库，应该没事吧？ 不一定。如果私有仓库的访问控制配置不当，或者你的 GitHub 账号被盗，敏感信息依然会泄露。安全上没有绝对。

• 删除文件后，别人还能通过历史记录找到吗？ 是的。git log --all --full-history -- .env 命令可以查看文件的所有历史版本。

• 我必须使用 BFG 或 filter-repo 吗？用 git filter-branch 不行吗？ git filter-branch 是官方工具，但速度极慢且容易出错。BFG 和 git filter-repo 是社区开发的替代品，性能更好，推荐优先使用。

• 我只是提交了一个测试用的假密码，需要这么紧张吗？ 需要。安全习惯是肌肉记忆，不能因为是测试环境就放松警惕。假密码可能被用来猜测你的密码命名规则。

错法对照

错法	问题	正解
将数据库密码硬编码在 Java 代码中	任何能访问代码的人都能看到密码	使用 System.getenv() 读取环境变量
提交 .env 文件到仓库	敏感信息永久留在历史中	将 .env 加入 .gitignore
仅删除文件并提交新版本	历史记录中依然存在	使用 BFG 或 filter-repo 清除历史
在团队群聊中发送密钥	聊天记录可能被泄露或截图	使用密码管理器或安全的密钥共享工具
认为私有仓库绝对安全	访问控制可能被绕过或账号被盗	无论公开私有，都遵循最小权限原则

卡点急救

1. 我不小心把 AWS Access Key 推送到 GitHub 了：立即登录 AWS IAM 控制台，禁用并删除该 Access Key，然后生成一个新的。接着按照步骤 3 清除 Git 历史记录。
2. 我执行了 git push --force，现在同事的代码全乱了：这是强制推送的正常后果。立即通知所有团队成员，让他们不要执行 git pull，而是重新克隆仓库，或者执行 git fetch origin 和 git reset --hard origin/main。
3. 我不确定我的项目里有没有泄露密钥：可以使用工具如 gitleaks 或 truffleHog 扫描你的 Git 历史记录，它们能自动检测常见的密钥格式。

面试常问

• 如何防止敏感信息进入代码仓库？ 三层防护：第一层是 .gitignore，第二层是代码审查（Code Review），第三层是使用 git-secrets 等工具在提交前自动扫描。

• 如果发现敏感信息已经泄露，第一步应该做什么？ 立即撤销（Revoke）或轮换（Rotate）泄露的凭证。这是止血的关键，然后再清理 Git 历史记录。

• 什么是密钥管理服务（KMS）？ 它是一个集中化的系统，用于安全地存储、管理和访问加密密钥和敏感配置。应用程序在运行时通过 API 调用获取密钥，而不是将密钥存储在代码或环境变量中。

自测三问

1. 为什么 .gitignore 无法忽略一个已经被 Git 跟踪的文件？
2. 除了环境变量，还有哪些方式可以管理应用程序的敏感配置？
3. 如果你需要与团队成员共享一个 API 密钥，最佳实践是什么？

小结一句话

安全习惯的核心是：永远假设你的代码会被公开，永远不要在代码中存放秘密，永远为错误准备好补救方案。

延伸

• GitHub 文档：从仓库中删除敏感数据
• 下一课：路线图对照——回顾整个学习路径，查漏补缺。