Git 快速上手 讲的是「一个人怎么用」。 但真实项目里 Git 是社交工具 —— 提交怎么写、PR 怎么提、 冲突怎么解，背后都是人和人的协作。这篇讲一群人怎么用。

一、分支模型：选简单的那个

业界有名气好几种分支模型，按团队规模选：

GitHub Flow（推荐小团队）

main 永远是可部署的
  │
  ├─ feature/login    开发中
  ├─ fix/header-bug   修 bug 中
  └─ 每个任务一个分支，做完 PR 合回 main

规则就两条：main 永远是好的；所有改动走 PR。 简单、够用，五个人以内闭眼选。

Git Flow（大版本产品）

main（生产）  ←  develop（开发主干）  ←  feature/*（功能）
                    ↑
              release/*（发版预演）  hotfix/*（线上急救）

适合「版本发布周期明确」的产品（客户端、传统软件）。 互联网团队用这个的越来越少 —— 流程太重， 一个 bug 修复要经过三层分支，救火来不及。

我的建议

没想清楚就用 GitHub Flow。等觉得疼了（发版混乱、环境不一致） 再演进。流程是解决具体问题的，不是用来显专业的。

二、分支命名规范

feature/用户模块-登录      新功能
fix/购物车数量显示错误      修 bug
hotfix/支付接口超时         线上急救
refactor/订单服务拆分        重构
docs/更新部署文档           纯文档
chore/升级依赖版本         杂活

规则：类型/简短描述，全小写或拼音都行，关键是团队一致。 看见 fix/xxx 就知道该 cherry-pick 到哪个紧急分支， 看见 chore/xxx 就知道 review 可以走个过场。

三、提交信息：写给三个月后的人看

格式

<type>: <一句话摘要（不超过 50 字）>

为什么改（背景、问题现象）
改了什么（方案简述）
影响范围（可选）

Closes #123（关联 issue）

示例

fix: 修复购物车数量在iOS上显示为0的问题

iOS Safari 对 input[type=number] 的 readonly 处理有差异，
用户改数量后旧值没清掉，导致提交时数量为0。
改为受控组件 + 手动同步 state。

Closes #456

对比 update、fix bug、改了购物车 这种「三无提交」—— 前者是文档，后者是天书。Commit message 是写给 「半夜被叫起来查问题的自己」的情书。

铁律

• 一个提交只做一件事。修 bug 别顺手重构， review 的人会裂开，回滚的时候更裂；
• 提交前 git diff 自己看一遍。我见过提交里混进 console.log 和本地调试代码的，不止一次；
• 别提交 node_modules、.env、编译产物 （.gitignore 见本站仓库根目录）。

四、Pull Request：协作的主战场

提 PR 前自查

git fetch origin
git rebase origin/main      # 把最新主干变基进来，减少冲突
npm test                    # 测试过了再提
git log origin/main..HEAD  # 看看这几个提交像不像样

PR 描述写什么

## 改了什么
购物车数量选择器改为受控组件

## 为什么
#456 iOS 上数量显示为 0

## 怎么验证的
1. iOS Safari 打开购物车
2. 改数量为 3，提交订单
3. 订单详情显示 3 ✓

## 影响范围
仅购物车页，无数据库变更

review 的人最怕「点开 PR 不知道你在干嘛」。 PR 描述的质量，决定 review 的速度。

PR 大小原则

一个 PR 不超过 400 行有效改动（不含生成的文件）。 超过就拆。大 PR 的结果是：review 的人划划水点个 approve， 真 bug 混进去没人发现。小 PR 审得细，合得快，回滚容易。

五、Code Review 礼仪

提意见的

• 对事不对人：说「这个循环在数据量大时会慢」， 不说「你这写的是什么」；
• 给方案不给指示：与其说「改成用 reduce」， 不如说「这里考虑过用 reduce 吗？我觉得可读性更好」；
• 区分必须改和建议改：[blocking] 和 [nit] 标清楚， 别让小问题卡住合并；
• 及时：PR 挂三天没人看，提的人早换任务了。 团队里可以约定「24 小时内必须响应」。

被 review 的

• 别护代码。别人挑问题是帮你兜底，不是找你茬；
• 有不同意见说出来，沉默的合并等于埋雷；
• 改完回复每一条评论（哪怕回个「已改」）， 这是对 review 者的尊重。

六、冲突：正面刚，别绕

合并冲突不是事故，是日常。流程：

git fetch origin
git rebase origin/main     # 或者 merge，看团队习惯
# 冲突了，Git 会告诉你哪些文件

打开文件，看见：

<<<<<<< HEAD
你的版本
=======
对方的版本
>>>>>>> origin/main

怎么解：

1. 搞懂两边各自的意图（不行就问对方，别瞎猜）；
2. 保留该保留的，删标记；
3. git add 解决完的文件，git rebase --continue；
4. 解完必须跑一遍测试 —— 冲突解错是「静默错误」， 编译能过，逻辑全错，这种 bug 最难查。

七、rebase 还是 merge？

团队里常见的「圣战」，一句话版：

• rebase：历史干净（一条直线），但改写了提交哈希。 只对「还没推送的本地提交」用；
• merge：保留真实历史，多一个合并提交，但安全。 多人协作的分支，合回主干用 merge。

铁律：已经 push 的公共提交，永远不要 rebase —— 你会成为团队的公敌（别人的提交历史全乱了）。

八、保护主干

GitHub 仓库 Settings → Branches 加规则：

main 分支：
  - 必须通过 PR 才能合并
  - 必须至少 1 人 approve
  - 必须通过 CI（测试、lint）
  - 禁止 force push

这四条是团队代码质量的底线。没有保护的主干， 迟早有人 git push --force 上来，一锅端。

小结

团队 Git 的核心不是命令，是约定：分支怎么命名、 提交怎么写、PR 多大、多久 review。命令半小时学会， 约定磨合半年。本站这套流程（feature 分支 + PR + 主干保护）， 就是你现在这个仓库在用的 —— 去看看 commit 历史和 .github/workflows/deploy.yml，活样本。