GitHub Flow
May 28, 2026 · View on GitHub
GitHub Flow 是一种轻量分支工作流，适合主分支稳定、发布频繁、CI 完整的小团队和 Web 服务。
它的核心思路是：主分支保持可发布，所有变更通过短分支和 PR 合入。
在企业团队里，GitHub Flow 不应停留在轻量流程本身。配合分支保护、CODEOWNERS、Rulesets、Merge Queue、Actions 和安全扫描后，它可以演进成一套完整的 GitHub 协作配置栈。
流程
main -> branch -> pull request -> review -> CI -> merge -> deploy
适合场景
- Web 服务
- 小团队或中等规模团队
- 发布频率高
- 自动化测试和 CI 较完善
- 出问题可以快速回滚
基本规则
main始终保持可发布- 每个变更创建短分支
- 每个分支通过 PR 合入
- 合入前至少完成 Review 和 CI
- 合入后尽快部署
- 出问题优先 revert
分支生命周期
GitHub Flow 不鼓励长期存在的 feature 分支。
如果一个功能需要开发很久，建议拆小：
- 先合入无行为变化的准备性重构
- 再合入后端能力
- 再合入前端入口
- 未完成能力用 feature flag 控制
常见误区
1. main 没有保护
如果所有人都能直接 push 到 main，GitHub Flow 很快会变成混乱的集中式提交。
至少需要：
- Require pull request
- Required status checks
- Required review
2. PR 太大
GitHub Flow 依赖快速 Review。
PR 太大时，Review 会流于形式。
3. 没有发布和回滚机制
GitHub Flow 适合高频发布，但前提是发布和回滚足够稳。
企业化配置
建议最小配置：
main启用分支保护- 所有变更走 PR
- CODEOWNERS 覆盖关键目录
- CI 配成 required status checks
- 安全扫描前移到 PR 或 push 阶段
- PR 高并发后启用 Merge Queue
- 合入后能追踪 tag、release 和部署状态