Git 工作流对比：GitHub Flow vs Git Flow vs Trunk-based 选型指南
分支人人会用，但怎么管理分支，不同团队有不同的做法。这就是 Git 工作流要解决的问题：谁可以往哪个分支提交，什么时候合并，版本号怎么定，发布流程怎么走。
很多团队在选工作流的时候纠结很久，其实没有完美的方案——只有最适合你的那一种。这篇文章把三种主流工作流拆开讲清楚，你对照自己的情况选就是了。
GitHub Flow：最简单
GitHub Flow 是 GitHub 官方推荐的流程，规则少到只有六条，非常适合互联网产品的开发节奏。
六条规则
第一，main 分支永远可部署。任何时刻 main 上的代码都应该是能直接上线的状态。这意味着你必须有自动化测试和 CI 来保证 main 分支的质量。
第二，新工作从 main 分支创建新分支。分支名要描述性，比如 add-search-api 而不是 patch-1 或 test-branch。好的分支名让人一眼就知道这个分支在做什么，方便在 PR 列表里浏览。
第三，频繁推送到远程同名分支。不要本地攒一堆提交再推，随时推上去让别人看到进度。这也能防止本地丢失代码（有时候硬盘坏了就什么都没了）。远程推送也是一种备份。
第四，通过 Pull Request 合并。把分支推上去后，在 GitHub 上提 PR，让同事 review 代码。PR 是代码审查的核心载体，也是知识传递和经验共享的重要方式。
第五，合并后立即部署。PR 合并到 main 之后自动部署，GitHub Flow 通常配合 CI/CD 使用。很多团队用的是"合并即部署"的模式，PR 合并的那一刻，CI/CD 流水线就自动把代码部署到线上。
第六，合并后删除分支。分支用完就删，保持仓库干净。GitHub 上有个"Delete branch"按钮，PR 合并后会自动出现。养成好习惯，不要让已合并的分支堆成山。
适合谁？
持续部署的 Web 应用、小团队（2-10人）、迭代快的项目。如果你每周甚至每天都要发版，GitHub Flow 最合适。大多数 SaaS 产品、前端项目、个人开源项目都适合这个流程。
Git Flow：最严谨
Git Flow 定义了一套严格的分支模型，适合版本发布周期较长的项目。这套模型 2010 年发布，曾经是事实上的工业标准，直到现在还有大量企业项目在用。
五个分支
Git Flow 定义了五种类型的分支：
核心分支有两个：main 和 develop。main 只存已发布的代码（每个 commit 理论上对应一个线上版本），develop 是日常开发的集成分支。
功能分支（feature）：功能开发从 develop 分支创建 feature 分支（feature/search），做完合并回 develop。功能分支可以存在较长时间，只要还没做完就不合并。
发布分支（release）：准备发布前从 develop 创建 release 分支（release/v1.5.0），在这个分支上修 bug、更新版本号、写发布说明、做最后的打磨。准备就绪后，release 分支同时合并到 main 和 develop（因为修的热修复也得带到下一次开发中）。
热修复分支（hotfix）：线上出现紧急 bug，从 main 创建 hotfix 分支（hotfix/fix-crash），修完也同时合并到 main 和 develop。这是唯一可以直接操作 main 的场景。
看起来复杂？
这个流程解决的问题是真实的：当一个项目同时维护多个版本时（比如 v1.5 还在修 bug，v2.0 正在开发，v2.1 已经规划好了），Git Flow 的分支模型能让各条线互不干扰。这也是为什么桌面软件、移动应用、SDK 这类产品还在广泛采用 Git Flow。
适合谁？
桌面软件、移动应用、SDK、嵌入式系统等有明确版本号、发布周期以周或月为单位的团队。如果你的产品需要支持多个客户端版本（不能强制用户升级），Git Flow 的 release 和 hotfix 机制非常有用。
Git Flow 的简化方案
很多团队觉得 Git Flow 太重，做了一些简化，比如：
- 取消 develop 分支，feature 分支直接从 main 创建，release 后合并回 main。（这其实就是 GitHub Flow 加 release 分支）
- 保留 develop 但去掉 hotfix 分支，热修复也在 develop 上做。
- 合并时用 squash merge，避免产生过多琐碎提交。
关键是根据自己的实际需求裁剪，没必要完全照搬。
Trunk-based Development：最激进
Trunk-based 的核心思想是：所有人每天往 main 分支提交代码。
怎么运作
没有 develop 分支，没有长期存在的 feature 分支。如果需要开发大功能，用"特性开关"（Feature Flag）把未完成的功能隐藏起来，代码照样提交到 main，只是用户看不到。这样避免了长期分支带来的合并地狱。
分支生命周期极短，通常不超过一天。今天建的分支，今天完成，今晚合并，明天删除。如果一个功能一天做不完，就把它拆成多个小步骤，每步用特性开关控制是否可见。
看起来违反直觉
所有人往同一个分支提交，不会乱吗？关键在于自动化。Trunk-based 必须配合强大的 CI 系统：每次提交都自动跑测试和代码检查。测试不通过就阻止合并。通常还要求代码覆盖率保持在较高水平（80%以上），因为每个人都在 trunk 上工作，没有长期分支的"缓冲"。
适合谁？
有成熟 CI/CD 体系、测试覆盖率高的工程团队。Google、Facebook、Netflix 这些公司都用类似的模式。据 Google 的数据，他们整个代码仓库（数十亿行代码）都是使用 Trunk-based 方式在管理的，所有开发者每天向同一个主干提交代码，这在外人看来似乎很混乱，但在强大的自动化工具链支撑下运行得非常顺畅。
对团队的要求
Trunk-based 工作量并要求最严：所有开发者需要频繁地跟主干同步（每天至少一次），必须有成熟的特性开关系统，CI 体系必须可靠且快速（如果一次运行需要几个小时，就没有人愿意频繁更新了）。不适合分布式大团队或有外包参与的项目。
怎么选
三个流程没有绝对的好坏，关键看你的实际情况。
| 维度 | GitHub Flow | Git Flow | Trunk-based |
|---|---|---|---|
| 复杂度 | 低 | 高 | 中 |
| 分支数量 | 少 | 多 | 极少 |
| CI/CD 要求 | 基础 | 中等 | 极高 |
| 适合团队规模 | 小中型中到大型 | ||
| 发布频率 | 高（每天） | 低（每周/月） | 高（持续） |
| 版本管理 | 简单 | 严格 | 不需要 |
个人项目或小团队：GitHub Flow。规则少，学习成本低，够用了。
有版本发布周期的产品：Git Flow。分支职责清晰，版本管理规范。
大型团队、持续部署：Trunk-based。对自动化要求高，但效率最高。
折中方案：GitHub Flow 加 release 分支。日常开发走 GitHub Flow，发布前从 main 切一个 release 分支做最后准备。兼顾简单和规范，很多实际团队在用这个模式。
一个核心原则
不管选哪条工作流，有一条原则是共同的：main 分支永远是可用的。
main 分支坏了意味着所有人的工作都受影响。所以要有保护规则：不能直接往 main 提交，必须通过 PR 合并，PR 必须经过 review，CI 必须通过。在 GitHub 仓库的 Settings → Branches → Branch Protection Rules 里配置这些规则，只需几分钟。
这个原则的另一个含义是：永远不要让 main 分支处于不可部署的状态。 每次提交 main 都应该是一个可以上线的版本。如果某个功能还没做完，用特性开关把它隐藏，不要让它影响其他功能的正常发布。
最后
工作流是工具，不是教条。很多团队会根据实际情况调整，比如 Git Flow 简化版、GitHub Flow 加 release 分支。关键是团队每个人都理解并遵守同一个规则。
建议你先从 GitHub Flow 开始，随着团队和项目复杂度增加，再考虑更复杂的流程。过早引入复杂的流程会让团队产生抵触心理，反而降低效率。简单、可执行、团队都能遵守——这才是最好的工作流。