Chapter 07

常用工作流模式

了解主流 Git 工作流的核心差异，掌握 Feature Branch 从创建到合并的完整流程与团队协作规范。

工作流对比

什么是集中式工作流？

所有开发者直接在 main 分支上工作，用 git pull 同步后 git push 提交。这是最简单的工作流，但多人同时修改同一文件时极易产生合并冲突。仅适合 2-3 人的小项目或个人项目。

什么是 Feature Branch 工作流？

每个新功能或修复都从 main 创建独立分支（如 feature/login），开发完成后通过 Pull Request 合并回 main。相比直接在 main 上开发有三个核心优势：隔离变更——不同功能互不干扰；便于 Code Review——PR 天然提供 diff 和讨论界面；可随时放弃——不合意的分支直接删除，main 不受影响。这是目前最广泛使用的工作流。

什么是 Git Flow？

由 Vincent Driessen 提出的经典模型，定义了五种分支类型：main（生产代码，始终可部署）、develop（开发集成分支）、feature/*（从 develop 创建，完成后合回 develop）、release/*（从 develop 拉出，做发布前测试和版本号更新，最终合入 main 和 develop）、hotfix/*（从 main 拉出，紧急修复后合回 main 和 develop）。

适用场景

Git Flow 分支模型较复杂，适合有明确版本发布节奏的项目（如桌面软件、移动 App）。对于持续部署的 Web 项目，GitHub Flow 通常更合适。

什么是 GitHub Flow？

简化版工作流：main 分支始终可部署 + 每个功能建分支 + PR 合并后立即部署。与 Git Flow 相比去掉了 develop、release、hotfix 分支，大幅降低复杂度。核心原则是 main 永远处于可发布状态，任何不确定的改动都在功能分支上完成。

实践规范

什么是 Code Review？

PR 创建后，至少需要一位团队成员审查代码。Review 的方式包括：

评论（Comment）——对某行代码提出疑问或建议
批准（Approve）——代码没问题，同意合并
请求修改（Request Changes）——发现问题，需要修改后重新审查

Code Review 能有效减少 bug、统一代码风格、促进团队知识共享。

一个功能从开始到合并的完整流程是什么？

git switch -c feature/login       # 1. 从 main 创建功能分支
# ... 编写代码 ...
git add .                          # 2. 暂存变更
git commit -m "feat(auth): ..."    # 3. 提交
git push -u origin feature/login   # 4. 推送到远程
# 5. 在 GitHub/GitLab 创建 Pull Request
# 6. 团队 Review，修改直到通过
git switch main                    # 7. 合并后切回 main
git pull                           # 8. 拉取最新代码
git branch -d feature/login        # 9. 删除本地功能分支

关键原则

分支生命周期：创建 → 开发 → PR → Review → 合并 → 删除。功能分支是临时的，合并后应立即删除。

commit message 有什么规范？

业界广泛采用 Conventional Commits 规范，格式为 type(scope): description：

feat(auth): add login page          # 新功能
fix(api): handle null response      # 修复 bug
docs: update README                 # 文档变更
refactor(utils): extract helper     # 重构（不改变行为）
test(auth): add login test cases    # 测试
chore: upgrade dependencies         # 构建/工具变更

常用 type：feat、fix、docs、refactor、test、chore。规范化的 message 可自动生成 CHANGELOG 和语义化版本号。

什么是 squash merge？

将 PR 中的所有 commit 压缩为一个 commit 再合并到 main，保持主分支历史线性干净。对应的命令是 git merge --squash：

git switch main
git merge --squash feature/login   # 将功能分支所有变更压入暂存区
git commit -m "feat(auth): add login feature (#1)"  # 创建单个 commit

在 GitHub PR 界面也可以选择 "Squash and merge" 按钮直接完成。适合功能分支有很多细碎 commit（如 "wip"、"fix typo"）的场景。

什么是 partial clone 和 sparse checkout？

对于体积庞大的仓库，可以只克隆部分内容以节省时间和磁盘：

# partial clone：不立即下载文件内容，按需获取
git clone --filter=blob:none https://github.com/example/repo.git

# sparse checkout：只检出指定目录
git clone --filter=blob:none --sparse https://github.com/example/repo.git
cd repo
git sparse-checkout set src/core docs

--filter=blob:none 只下载 commit 树结构，文件内容在访问时才拉取。sparse-checkout 则进一步限制工作目录中只出现指定路径。两者常组合使用于大型 monorepo 场景。

Feature Branch 工作流练习

Welcome to Feature Branch Workflow Demo

按照步骤提示，体验完整的功能分支工作流。输入 help 查看所有命令。

~/project $