4、版本控制：Git与GitHub的配置、分支策略、代码提交规范

版本控制这件事，说白了就是给项目装一台“时光机”。

我刚入行那会儿，团队还在用 FTP 传代码，文件名后面带日期是常态。后来有一次上线前发现改错了，想回退？没门。那之后我就彻底倒向了 Git。今天这章，我把这几年在 Git 和 GitHub 上踩过的坑、总结出的好习惯，一次性说清楚。

4.1 Git 基础配置：别让工具拖后腿

装好 Git 之后，第一件事不是 clone 仓库，而是配好身份信息。我见过太多人跳过这步，结果提交记录里显示的是“unknown”。

git config --global user.name "你的名字"
git config --global user.email "你的邮箱@example.com"

嗯，这里要注意：邮箱最好和 GitHub 注册邮箱一致，不然你的 commit 不会关联到 GitHub 头像。

我个人习惯还会配几个别名，省时间：

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.lg "log --oneline --graph --all --decorate"
小技巧： 用 git lg 看提交历史，比默认的 log 清晰十倍。分支、合并、分叉一目了然。

4.2 GitHub 配置：SSH 密钥与远程仓库

配好本地 Git 之后，下一步就是连 GitHub。我个人强烈推荐用 SSH 方式，而不是 HTTPS。为什么？因为不用每次 push 都输密码。

生成密钥很简单：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

一路回车，然后在 ~/.ssh/id_ed25519.pub 里拿到公钥，粘贴到 GitHub 的 Settings → SSH and GPG keys 里。

我曾经有一次因为换了电脑，忘了配 SSH，结果 push 的时候一直报权限错误。排查了半天才发现是公钥没加。嗯，从那以后我每次换设备第一件事就是配 SSH。

验证是否成功：

ssh -T git@github.com
# 输出：Hi xxx! You've successfully authenticated...

4.3 分支策略：选对模型，少走弯路

分支策略这东西，没有银弹。但如果你问我，小团队用什么最省心？我会说：GitHub Flow。

它的核心规则就几条：

  • main 分支永远是可部署的
  • 新功能从 main 拉出特性分支
  • 开发完成后提 Pull Request
  • Code Review 通过后合并回 main
  • 合并后立即部署

你想想看，这套流程简单到几乎没有学习成本。我在一个 10 人团队里用了两年，从来没出过问题。

但如果是大项目、多版本并行，那就得用 Git Flow 了。它多了 develop、release、hotfix 分支，结构更重，但控制力更强。

分支模型 适用场景 优点 缺点
GitHub Flow 小团队、持续部署 简单、快速 多版本并行时混乱
Git Flow 大项目、版本发布 结构清晰、控制力强 分支多、操作繁琐
Trunk-Based CI/CD 成熟团队 极简、冲突少 对测试要求极高
我的建议： 刚开始用 GitHub Flow 就够了。等团队超过 20 人、需要同时维护多个版本时，再考虑 Git Flow。

下面这张图，把三种分支模型的核心流程画出来了：

三种分支模型对比 三种分支模型核心流程对比 GitHub Flow main feature/xxx PR → main Git Flow main develop feature/xxx release/x.x Trunk-Based trunk 短生命周期分支 说明 GitHub Flow：轻量、快速 Git Flow：结构完整、控制强 Trunk-Based：极简、适合CI/CD

4.4 代码提交规范：让历史可读

提交信息写得好不好，直接决定你三个月后能不能看懂自己在干什么。

我推荐用 Conventional Commits 规范。格式很简单：

<类型>: <简短描述>

[可选正文]

[可选脚注]

类型用这几个就够了：

  • feat — 新功能
  • fix — 修复 bug
  • docs — 文档变更
  • refactor — 重构
  • test — 测试相关
  • chore — 杂项（构建、依赖等）

举个例子：

feat: 添加用户登录接口

实现基于 JWT 的登录认证，包含 token 刷新逻辑。

Closes #42

我曾经在一个项目里看到过这样的提交信息：“fix bug”、“update”、“改了点东西”。你想想看，这种信息跟没写有什么区别？后来我强制团队用规范，配合 commitlint 做自动化检查，才彻底改掉这个毛病。

注意： 提交信息不要超过 50 个字符（英文）。中文可以适当放宽，但尽量控制在 80 字以内。太长的描述放到正文里。

4.5 避坑指南：我踩过的那些坑

最后分享几个实战中容易翻车的地方：

  • 不要直接往 main 分支 push。 我曾经有一次手快，把未测试的代码直接 push 到了 main，结果 CI 全红，同事追着我问了一下午。从那以后我养成了习惯：main 分支加保护，必须走 PR。
  • 合并前先 rebase。 我个人习惯在合并 PR 之前，先把特性分支 rebase 到最新的 main 上，这样历史是一条直线，看着清爽。
  • .gitignore 要提前配好。 我见过有人把 node_modules 和 .env 都提交上去了。嗯，这很尴尬。建议一开始就配好模板。
  • 提交前先 diff。 用 git diff --staged 看一眼，确认没有遗留的调试代码或敏感信息。
推荐工具： 用 husky + lint-staged 在提交前自动检查代码格式和规范。省心省力。

版本控制这件事，说到底是为了让团队协作更顺畅，让历史可追溯。工具是死的，习惯是活的。把基础配好、策略选对、规范定死，剩下的就是坚持执行。

← 上一章 📖 返回目录 下一章 →