GitHub Flow 是什么
GitHub Flow 是一条轻量流程：只保留一条长期分支（通常是 main），任何改动都走「从 main 开分支 → 提交 → 开 PR → 评审 → 合并 → 删除分支」。它的前提是 main 始终处于可部署状态，因此合并动作本身就可以视作一个发布信号。相比 GitFlow，它没有 develop 与 release 分支的层层流转，适合持续部署、发布频繁的 Web 服务与制品团队。
基本信息
| 长期分支 | 仅 main，保持可部署 |
|---|---|
| 流程 | 开分支 → 提交 → PR → 评审 → 合并 → 删除分支 |
| 适用 | 持续部署、发布频繁的团队 |
| 关键前提 | 主干始终可部署，配套测试与自动化 |
| 平台 | GitHub 官方提出，任何平台可实践 |
典型使用场景
- Web 服务按天或按周持续交付
- 小团队希望流程简单、减少分支层级
- 改动通过 PR 评审后即可直接部署
- 制品发布频繁，不需要独立冻结期
- 用特性开关隔离未完成功能，代码先合入
- 作为新手团队的第一套协作流程逐步演进
流程示例
流程示例
git switch main && git pull # 从最新主干开始
git switch -c feature/login # 为本次改动开分支
git commit -m 'feat: add sso login' # 小步提交
git push -u origin feature/login # 推送并建立跟踪
# 平台上发起 PR，评审通过后合并并删除分支与 GitFlow 的差别
| 维度 | GitHub Flow | GitFlow |
|---|---|---|
| 长期分支 | 仅 main | main 与 develop |
| 发布方式 | 合并即可部署 | 另走 release 分支 |
| 流程复杂度 | 低 | 高 |
官方文档把「main 随时可部署」作为前提，合并动作等价于可发布信号；这要求主干具备可回退的部署能力。
合并方式会影响回滚粒度：需要按功能回滚时选合并提交，追求线性历史则用压缩或变基，团队应统一约定。
落地这套流程的几个前提
- 主干具备自动化测试与可回退的部署能力
- 分支开得足够小，PR 能在一天内评审完成
- 合并方式在仓库设置里统一，避免历史风格混杂
- 回滚方案提前演练过，而不是等出故障时再想