👥 第十一章：协作工作流 —— 团队作战

Gitflow 工作流

Gitflow 是一种经典的分支管理策略，适合有计划发布版本的项目。

Gitflow 分支结构：

main ─────●────────────────●───────────●─── (生产环境)
          │                ↑           ↑
          │                │           │
release ──┼──────●─────────┘           │
          │      ↑                     │
          │      │                     │
develop ──●──●───●──●──●──●──●──●─────┘──●── (开发主线)
               ↑     ↑        ↑
               │     │        │
feature/xxx ───┘     │        │
feature/yyy ─────────┘        │
bugfix/zzz ───────────────────┘

分支说明：
• main: 生产环境的代码，只接受 release 和 hotfix 的合并
• develop: 开发主线，所有功能分支的汇聚点
• feature/*: 功能分支，从 develop 创建，完成后合并回 develop
• release/*: 发布分支，从 develop 创建，测试通过后合并到 main 和 develop
• hotfix/*: 紧急修复分支，从 main 创建，修复后合并到 main 和 develop

GitHub Flow —— 简单就是美

GitHub Flow 比 Gitflow 简单得多，适合持续部署的项目。

GitHub Flow 流程：

1. main 分支始终可部署
2. 从 main 创建描述性分支（如 add-login-page）
3. 在分支上开发并提交
4. 发起 Pull Request
5. 代码审查通过后合并到 main
6. 合并后立即部署

main ──●──●──●──────●──────●── (始终可部署)
        ↑     ↑      ↑
        │     │      │
   feat/a ──┘     │
   PR + merge     │
                   │
         feat/b ───┘
         PR + merge

Forking 工作流 —— 开源项目的标准

在开源项目中，你通常没有直接 push 的权限。流程是：

# 1. 在 GitHub 上 Fork 仓库到你的账号下

# 2. 克隆你自己的 Fork
git clone git@github.com:小明/开源项目.git
cd 开源项目

# 3. 添加原始仓库为 upstream
git remote add upstream git@github.com:原作者/开源项目.git

# 4. 创建功能分支
git switch -c fix/修复文档错误

# 5. 开发、提交、推送
git add .
git commit -m "docs: 修复 README 中的拼写错误"
git push origin fix/修复文档错误

# 6. 在 GitHub 上发起 Pull Request

# 7. 同步上游的最新代码
git fetch upstream
git switch main
git merge upstream/main
git push origin main

Pull Request 的最佳实践

• 一个 PR 只做一件事——不要在一个 PR 里既加功能又修 bug 还重构代码
• 写清楚 PR 描述——说明改了什么、为什么改、怎么测试
• 保持 PR 小而精——一个 3000 行的 PR 没人想 review
• 及时响应 review 意见——别让 reviewer 等太久
• 合并前确保 CI 通过——不要让测试挂掉的代码进 main