CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
Git/GitHub 入门实战/课时/安全习惯
RawBlame
课时目录12 节

Git/GitHub 入门实战

  1. 01Git 基础概念
  2. 02基本 Git 操作
  3. 03Git 进阶
  4. 04GitHub 入门
  5. 05协作基础
  6. 06分支工作流
  7. 07Pull Request
  8. 08Issues 管理
  9. 09团队协作
  10. 10安全习惯
  11. 11路线图对照
  12. 12综合练习

安全习惯

密钥与 .gitignore。

25 分钟

安全习惯

这一课你将能做到

  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、数据库控制台),修改所有泄露的凭证。旧密码已经不安全了。

  • 从历史中彻底删除文件(使用 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
    
  • 通知团队成员:告诉他们你已经强制推送了新的历史记录,他们需要重新克隆仓库或执行 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 文档:从仓库中删除敏感数据
    • 下一课:路线图对照——回顾整个学习路径,查漏补缺。
    加载本节练习…
    ← 上一课团队协作下一课 →路线图对照