没有万能的 Git 工作流。
选 Git 工作流，其实是在速度、安全、发布频率、团队规模和产品复杂度之间做取舍。
| 团队 / 产品 | 推荐工作流 | 适合原因 |
|---|---|---|
| 小团队 Web 产品 | GitHub Flow | 分支短、合入快、发布频繁 |
| 高频后端服务 | Trunk-Based Development | 主干稳定、CI 反馈快、回滚清晰 |
| 中大型业务团队 | Feature Branch + Protected Main | 兼顾并行开发和主分支稳定 |
| 开源项目 | Fork + Pull Request | 降低外部贡献者写权限风险 |
| 多版本交付产品 | Release Branch | 需要维护多个发布版本 |
| 多环境 SaaS / 企业内部平台 | GitLab Flow | 合入频率和上线频率不同，需要 production / stable 分支 |
| 移动端 / 客户端 | Release Branch + Hotfix | 发版周期长，线上版本分散 |
| 老系统维护 | Conservative Branch Strategy | 变更少、风险高，优先稳定 |
main -> feature branch -> pull request -> review -> CI -> merge -> deploy
main 始终可部署short-lived branch -> main -> CI -> deploy
GitHub Flow 更像 GitHub 平台上的轻量实现路径：短分支、PR、Review、合入默认分支。
Trunk-Based Development 更像组织原则：分支生命周期极短，团队围绕主干持续集成，主干保持可发布。
当 GitHub Flow 加上必需 CI、CODEOWNERS、Rulesets、Merge Queue、feature flag 和 release from main，它就已经很接近 trunk-based 的企业实现形态。
这是多数中大型业务团队的现实选择。
main 或 master 受保护GitHub 分支保护可要求 Review、状态检查、线性历史、合并队列等能力，官方说明见 protected branches。
Gitflow 适合版本发布节奏明确的产品，比如客户端、SDK、企业交付产品。
Gitflow 的分支模型有历史价值，但照搬到所有团队会制造额外复杂度。
GitLab Flow 适合发布频率和合入频率不完全一致的团队。
它保留 feature branch 和 merge request 的轻量协作方式，同时用 production、stable/* 这类分支表达线上状态和稳定版本线。
详细见 GitLab Flow。
fork -> branch -> commit -> pull request -> maintainer review -> merge
main -> release/1.8 -> bugfix -> tag -> hotfix -> back merge
Microsoft Release Flow 提供了一个更偏实战的组合：主干负责日常开发，按 sprint 或发布窗口创建 release 分支，修复完成后同步回主干。详细见 Microsoft Release Flow。
问题：合并风险越来越大，主干反馈失效。
建议：拆小任务，尽早合入，未完成能力用 feature flag 控制。
问题：主分支随时可能坏，责任边界不清。
建议：主分支保护，PR 审查，CI 必需通过。
问题：Review 变成形式。
建议：一个 PR 只解决一个问题，重构和行为变化分开。
问题：团队真实约束被忽略。
建议：按发布频率、团队规模、风险等级选择工作流。
| 实践 | 可借鉴点 |
|---|---|
| 阿里巴巴 AoneFlow | 用 release 分支表达发布范围，支持 feature 灵活组合和撤下 |
| 腾讯 Gitflow 分支规范 | 适合固定版本发布、release 测试、hotfix 回补的团队 |
| 字节跳动 Git 工作流 | 把分支、权限、Review、CI、发布放进统一研发设施 |
| Google 主干开发 | 用短分支、快 CI、小变更支撑大规模协作 |
| Microsoft Release Flow | 主干开发配合 release 分支，适合有固定发布窗口的产品团队 |
| Meta Sapling | 用堆叠提交表达大功能的连续小变更 |
这些案例不要直接照搬，先看自己的发布频率、团队规模、测试能力和线上回滚能力。
从旧流程迁移到新流程，不要一次改完所有规则。
推荐顺序：