第02章：标准团队工作流与分支策略

一套靠谱、可长期执行的 GitHub 团队流程

---

本章学习目标

• 掌握主分支保护 + 短生命周期分支的标准模型。
• 理解 Squash / Merge / Rebase 三种合并策略的适用场景。
• 会执行一个完整的“需求到合并”流程。

---

一、标准工作流（核心原则）

1. main/master 只放可发布代码。
2. 禁止直推，必须 PR。
3. 每个需求/修复一个分支，做完即删。
4. CI 必须通过后才能合并。
5. 至少 1 位同事 review。

---

二、分支命名规范（建议）

• 新功能：feat/<scope>-<short-desc>
• Bug 修复：fix/<scope>-<short-desc>
• 紧急修复：hotfix/<scope>-<short-desc>
• 重构：refactor/<scope>-<short-desc>
• 文档：docs/<scope>-<short-desc>

示例：

• feat/cart-coupon-stack
• fix/auth-token-refresh
• hotfix/payment-timeout

---

三、最常用命令流

git checkout main && git pull
git checkout -b feat/xxx
# 开发 + 本地自测
git add .
git commit -m "feat: add xxx"
git push -u origin feat/xxx
# 创建 PR -> Review + CI -> Merge

---

四、合并策略如何选

策略	优点	缺点	适合场景
Squash merge	历史简洁	丢失分支内细粒度提交	中小团队、追求干净历史
Merge commit	保留完整上下文	历史可能更“乱”	大团队、需追踪复杂合并
Rebase merge	线性历史好读	对新人要求更高	工程成熟团队

建议：团队统一一种主策略，不混用。

---

五、分支保护最低配置

• Require pull request before merging
• Require approvals（至少 1）
• Require status checks to pass（lint/test/build）
• Require conversation resolution
• Restrict pushes to main

---

六、Hotfix 快速修复流程

1. 从 main 拉 hotfix/* 分支。
2. 快速修复 + 最小回归测试。
3. PR 走“快速通道”（指定值班 reviewer）。
4. 合并后立即打补丁 tag（如 v1.2.3-hotfix.1）。
5. 补复盘 issue，避免同类问题复发。

---

七、落地动作

• 今天就做：开启 main 分支保护。
• 本周内做：统一命名规范与合并策略。
• 本月内做：把 hotfix 流程写成 SOP 并演练一次。