26. 工作流总览

什么是工作流

工作流就是团队协作时使用 Git 的规范。

什么时候建分支、怎么命名、什么时候合并、谁来 review——这些约定就是工作流。

没有”最好”的工作流，只有”最适合你团队”的工作流。选错了，轻则效率低，重则天天解冲突。

Git Flow

Git Flow 是最”重”的工作流。它定义了五类分支，各司其职。

分支结构

• main（历史资料多为 master）：存放正式发布的历史。每个提交都对应一个版本号。
• develop：日常开发的主战场。所有功能分支从这里分出去，最终合回来。
• feature/*：开发新功能时创建。从 develop 分出来，开发完合回 develop。
• release/*：准备发布时创建。从 develop 分出来，做测试和修 bug，最终合入 main 和 develop。
• hotfix/*：紧急修复线上 bug。从 main 分出来，修完合入 main 和 develop。

一个完整的流程

1. 项目初始化时，从 main 创建 develop 分支
2. 开发新功能：git switch -c feature/login develop（旧写法 git checkout -b feature/login develop）
3. 功能完成：合回 develop，删除 feature 分支
4. 准备发布：git switch -c release/1.0 develop
5. 发布完成：合入 main 并打标签，再合回 develop
6. 线上出 bug：git switch -c hotfix/1.0.1 main，修完合入 main 和 develop

适用场景

• 团队规模大（10 人以上）
• 项目有明确的版本发布周期
• 需要同时维护多个历史版本
• 对代码质量要求严格，有专门的测试阶段

优缺点

优点：结构清晰，各阶段隔离，适合严格的质量把控。

缺点：分支多、操作复杂。小团队用会觉得”杀鸡用牛刀”。

GitHub Flow

GitHub Flow 是 Git Flow 的极简版。核心就一条：main 分支永远可部署，新功能用分支开发，通过 Pull Request 合并。

流程

1. main 分支始终是可部署状态
2. 开发新功能时从 main 创建分支
3. 在分支上提交代码，定期推送到远程
4. 创建 Pull Request（PR），请求合并到 main
5. 团队成员在 PR 上 review 代码、讨论
6. review 通过后合并到 main，立即部署

没有 develop 分支

GitHub Flow 没有 develop 分支。所有功能分支直接面向 main。PR 就是临时的”集成测试”环节。

适用场景

• 持续部署/持续交付（CI/CD）的团队
• 团队规模小（2-10 人）
• 产品迭代快，没有长周期的版本规划
• 部署自动化程度高

优缺点

优点：简单、快速、适合敏捷开发。

缺点：没有专门的发布准备阶段。如果部署不够自动化，main 分支容易出问题。

Trunk-Based Development

Trunk-Based（基于主干）是最极端的方式。所有人都在同一个分支（trunk，通常是 main）上工作。

核心理念

• 开发者每天至少向主干合并一次代码
• 功能通过”特性开关”（feature flag）控制，而不是长期分支
• 分支最多活一天，超过一天就算”长命分支”

流程

1. 开发者从 main 创建短期分支（几小时到一天）
2. 频繁提交，频繁合并回 main
3. 未完成的功能用 feature flag 隐藏
4. 代码 review 通过工具在合并前完成

适用场景

• 高度自动化的 CI/CD 流水线
• 有完善的测试覆盖
• 资深开发者团队
• 大型开源项目（比如 Google、Facebook 的内部实践）

优缺点

优点：避免长期分支带来的合并地狱，集成频率高。

缺点：对团队能力要求高，需要完善的测试和 feature flag 体系。新手团队很难驾驭。

三种工作流对比

对比项	Git Flow	GitHub Flow	Trunk-Based
分支复杂度	高（5 类分支）	低（main + feature）	极低（main 为主）
发布节奏	版本制（周/月）	持续部署	持续部署
适合团队	大团队、传统软件	小团队、互联网产品	高度自动化团队
学习成本	高	低	中等
合并频率	低	中	高
质量保障	分支隔离 + 阶段测试	PR review + CI	CI + feature flag

如何选择

选 Git Flow 如果

• 你的产品有明确的版本号（比如 v1.0、v1.1）
• 需要同时维护多个线上版本
• 有专门的测试团队和发布流程

选 GitHub Flow 如果

• 你的团队在 2-10 人
• 部署自动化，能随时上线
• 没有复杂的版本管理需求
• 这是大多数互联网团队的最佳选择

选 Trunk-Based 如果

• 你的 CI/CD 非常成熟
• 测试覆盖率很高
• 团队成员有足够的自律和工程能力
• 你追求极致的集成速度

团队协作的基本原则

不管选哪种工作流，以下原则都适用：

1. 主分支永远可编译。main 分支上的代码应该是随时能上线的状态。

2. 分支要短命。活超过一周的分支容易产生合并冲突。

3. 频繁集成。越早合并，冲突越小。

4. 代码 review 不能省。PR 或 merge request 是保证质量的关键环节。

5. 提交信息要写清楚。未来的你会感谢现在的你。

6. 自动化一切能自动化的。测试、lint、构建、部署，都交给 CI/CD。

从简单开始

如果你刚起步，别一上来就用 Git Flow。

从 GitHub Flow 开始。等团队壮大了、流程复杂了，再考虑更重的方案。

工作流是为人服务的，不是反过来。能让你团队高效协作的，就是好工作流。

一句话总结：Git Flow 重规矩，GitHub Flow 重速度，Trunk-Based 重能力。选哪个取决于你的团队和项目，没有银弹。

这章学到了什么

• 三种主流工作流：Git Flow（重规矩）、GitHub Flow（重速度）、Trunk-Based（重能力）
• Git Flow 适合大团队、有明确发布周期的项目，结构清晰但操作复杂
• GitHub Flow 是极简版，main 永远可部署，通过 PR 合并，适合小团队和持续部署
• Trunk-Based 追求极致集成，所有人每天向主干合并，需要完善的 CI/CD 和测试体系
• 选择工作流没有银弹，建议从简单的 GitHub Flow 开始，按需升级

整套教程回顾：我们从 Git 是什么开始，一路走过了安装配置、基本操作、分支管理、远程协作，到高级技巧如 reflog、worktree、hooks，最后以工作流总览收尾。Git 的世界很大，但核心就是”版本控制”四个字——记录变更、随时回溯、协作不打架。继续实践，你会越来越得心应手。