GitFlow用了10年，谷歌早把它扔了：3种分支模型生死局

2013年，GitFlow还是行业圣经。到2023年，谷歌、Meta、Netflix的工程师听到这个词，表情像听到有人还在用IE6。

分支策略的迭代速度，比框架还快。这不是技术洁癖，是交付效率的生死线。

GitFlow：从标准答案到历史包袱

Vincent Driessen 2010年画出那张分支图时，没人质疑它的合理性。主分支（main）锁死生产环境，开发分支（develop）做集成，特性分支（feature/*）各自为战，发布分支（release/*）和热修分支（hotfix/*）层层把关。

这套设计像精密的手表——零件越多，故障点越多。

长期分支的噩梦是合并冲突。两个特性分支各自跑了两周，合并时发现底层接口变了，工程师得在凌晨两点做考古。更隐蔽的代价是交付延迟：功能明明写完了，卡在发布分支的审批队列里，等了两周才上生产。

云原生时代，这种"批量交付"模式成了笑话。微服务要求独立部署，GitFlow的层级审批反而成了绑腿沙袋。

GitHub Flow：大多数人其实在用这个

GitHub 2011年推出的简化版，把五层分支砍到两层：main分支永远可部署，特性分支从main切出，合并前走Pull Request（拉取请求，代码审查流程）。

很多团队以为自己还在用GitFlow，实际执行的是GitHub Flow。他们没有develop分支，特性分支直接合main，靠CI/CD（持续集成/持续部署，自动化构建发布流程）兜底。

区别很微妙：GitFlow问"这个功能属于哪个发布批次"，GitHub Flow问"这个功能现在能上线吗"。

后者的答案只有能或不能，决策成本骤降。但GitHub Flow有个隐藏前提：团队得有成熟的自动化测试。否则main分支频繁被打穿，生产事故会教你做人。

主干开发：谷歌的极端答案

Trunk-Based Development（主干开发，单一长期分支模式）更激进。所有工程师直接向main分支提交代码，一天多次。未完成的功能用特性开关（Feature Flags，运行时功能控制机制）隐藏，而不是藏在分支里。

谷歌的代码库有数十亿行，2.5万名工程师共享同一个主干分支。听起来像灾难？他们的解决方案是自动化到极致：提交前必须通过全部测试，代码审查由工具链强制执行，特性开关系统能在一分钟内回滚任何功能。

分支模型从"隔离风险"变成了"加速反馈"。

传统流程是：dev分支→test分支→prod分支，像工厂流水线。现代流程是：main分支→通过管道（pipeline，自动化部署流水线）→直达dev/test/prod。分支不再代表环境，环境由部署管道动态创建。

Azure DevOps的模板显示，这种模式下，从代码提交到生产部署可以压缩到分钟级。GitFlow时代，这个周期常以周计。

选择的本质是团队成熟度

三种模型没有绝对优劣，只有适配差异。GitFlow适合强监管行业——金融、医疗，需要审计痕迹和人为闸口。GitHub Flow是大多数SaaS团队的舒适区，平衡了速度与可控性。主干开发属于基础设施狂魔，测试覆盖率低于80%的团队尝试等于自杀。

一个信号值得注意：2024年DevOps调研报告显示，采用主干开发的团队，变更失败率比GitFlow团队低37%，但前置时间（lead time，从代码提交到上线的时长）中位数差距达到23倍。

快和稳的取舍，从来不只是技术问题。

你的团队现在用哪种分支策略？最近一次合并冲突花了多久解决？