结论：追求高频交付的团队选主干开发——所有人基于短命分支（几小时到几天）向 main 合入，配合特性开关（feature flag）把"部署"和"发布"解耦；GitFlow（develop/release/hotfix 多分支）适合版本化发布产品（客户端、需同时维护多版本），但合并地狱和长周期分支天然拖慢集成频率。现代 SaaS 团队的主流答案是主干开发。
展开：对 CI/CD 的连锁影响：1）主干开发下 CI 必须极快且极稳——每次合入即构建测试，流水线超过 10 分钟就会倒逼开发者攒大批次提交，恶性循环；需要特性开关体系（LaunchDarkly/Unleash）保证未完成功能安全上线。2）GitFlow 的分支多意味着流水线要为多分支建模，release 分支的冻结期里 bugfix 要双向合并（cherry-pick 回 develop），自动化成本高。3）折中方案 GitHub Flow（main + PR + 环境分支）适合小团队；发布火车（release train）给主干加固定发车节奏。度量视角：DORA 指标（部署频率、变更前置时间、变更失败率、恢复时间）本质都在鼓励小批量高频次，与主干开发互为因果。易错点：转主干开发不是"取消分支"而是缩短分支寿命，没有特性开关和自动化测试兜底就转，等于裸奔。
追问方向：特性开关的技术债管理（开关生命周期治理）、monorepo 与主干开发的相互强化关系。