核心要点
Git Flow：master/develop/feature/release/hotfix 多分支，适合发布周期长、需并行维护版本。
Trunk-Based：主干开发 + 短命分支 + 特性开关，适合持续交付/部署。
选择维度：发布频率、团队规模、CI/自动化测试成熟度。
高频发布 + 强 CI 选主干；版本化交付 + 多版本维护选 Git Flow。
标准回答
Git Flow
围绕长期分支组织：develop 集成、feature 开发新功能、release 准备发布、hotfix 修线上、master 存稳定版。结构清晰、适合按版本发布与多版本并行维护，但分支多、合并冲突和长命分支偏差较大。
Trunk-Based（主干开发）
所有人频繁向主干（trunk）小步合并，分支寿命短（数小时到一两天），未完成功能用特性开关隐藏。配合强 CI 能持续集成、持续交付，减少大合并地狱，是 DevOps 高效团队的主流选择。
如何选择
- 发布频率高、强 CI/自动化测试、追求持续交付 → Trunk-Based。
- 发布周期长、需维护多个历史版本、CI 较弱 → Git Flow（或 GitHub Flow 折中）。
核心是匹配团队的发布节奏与工程成熟度，而非追新。
常见误区
⚠️ 常见踩坑
在弱测试覆盖下强推主干开发，频繁合入易把主干搞坏；或在快速迭代的 Web 产品上硬套 Git Flow，导致流程冗重。
追问
追问 1：特性开关（Feature Toggle）有什么风险？
开关会增加分支逻辑与组合测试复杂度，长期不清理会形成「开关债」。应记录、设过期时间，功能稳定后及时移除并清理死代码。
追问 2：GitHub Flow 和上面两者什么关系？
GitHub Flow 是简化折中：只有主干 + 短命特性分支，经 PR 评审与 CI 后合并并部署。比 Git Flow 轻、比纯 Trunk-Based 更强调 PR 评审，适合中小团队的持续部署。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。