GitFlow用了12年，谷歌微软现在全扔了

2010年，一个荷兰程序员画了张分支图，全球开发者跟着跑了12年。现在那张图正在被撕碎——谷歌、Meta、亚马逊的代码库早就不这么玩了。

这张图叫GitFlow。它的发明者Vincent Driessen大概没想到，自己博客里的一个工作流程示意图，会成为一代开发者的"圣经"。main分支管生产，develop分支做集成，feature、release、hotfix三层分支层层套娃。听起来很严谨，像德国人的厨房。

但严谨是有代价的。

一个中等规模的团队，同时开着七八个feature分支是常态。合并代码像解九连环，冲突解决完，需求已经改了三版。Driessen本人在2020年更新博客，承认GitFlow是为"有预定发布周期的软件"设计的——翻译成人话：给没CI/CD（持续集成/持续交付）的年代准备的。

现在呢？Netflix一天部署上千次。按GitFlow的流程，release分支能排到明年。

GitHub Flow：把流程砍到只剩一把刀

2011年，GitHub的人看不下去了。他们搞了个极简版：main分支+功能分支，没了。

流程变成：从main切出新分支→改代码→提PR（Pull Request，拉取请求）→代码审查→合并回main→直接部署。没有develop，没有release，没有hotfix。需要紧急修复？切个分支，修完合并，和正常开发没区别。

这套玩法现在被无数团队用着，很多人甚至不知道它有个名字。GitHub官方文档说得很直白：「只要你的部署能自动化，这就够用了。」

但"够用"和"好用"是两件事。当团队扩大到几百人，main分支成了交通要道。A的功能没测完，B的代码要上线，怎么办？硬等？还是把没完工的代码也部署出去？

Trunk-Based Development：所有人挤在一条主干上

谷歌的答案是：所有人都往main分支塞代码，每天多次。听起来像自杀？他们有俩护身符。

第一个是自动化测试。代码合进去之前，成千上万条测试用例跑一遍，几分钟出结果。不过关就拒掉，没商量。谷歌2016年公开的报告显示，他们的主干开发配合大规模测试，让构建失败恢复时间从数小时降到分钟级。

第二个是功能开关（Feature Flags）。代码写完了，但功能藏在一个if语句后面。默认关闭，对用户不可见。想灰度测试？改个配置，放5%流量。出问题了？关掉开关，比回滚代码快十倍。

这套打法叫Trunk-Based Development（基于主干的开发）。Martin Fowler早在2013年就写过，但真正成为主流是近五年的事。State of DevOps报告连续几年把"主干开发+每日多次提交"列为高绩效团队的标志。

分支策略的演进，本质是交付节奏的战争。

GitFlow的年代，发布是仪式：定日期、打标签、写发布说明、全员待命。GitHub Flow把仪式砍了，但保留了"准备就绪才能上线"的安全感。Trunk-Based Development更激进：代码随时可上线， readiness（就绪状态）由自动化测试和开关共同担保。

Azure DevOps的文档里有个细节很说明问题。他们展示的现代流水线是这样的：main分支提交→自动触发构建→跑测试→部署到开发环境→人工审批或自动推进→生产环境。分支结构从"多层瀑布"变成了"单点放射"。

为什么大厂都在"开倒车"

有个反直觉的现象：Trunk-Based Development的分支数量比GitFlow更少，但代码隔离做得更好。秘密在那些开关系统里。

LaunchDarkly、Split、Unleash这些功能开关平台，现在都是独角兽或准独角兽。它们卖的不是技术，是"把发布和部署解耦"的能力。部署是技术动作，发布是商业决策。技术团队只管把代码弄上去，产品团队决定什么时候让用户看见。

Netflix工程师在2017年的技术博客写过：「我们每天有数百个功能开关同时存在，大部分永远不会被打开。」这听起来浪费，但换来的是极致的灵活性。A/B测试、灰度发布、紧急回滚，都在配置面板点几下完成。

国内大厂跟进得很快。阿里2019年全面推广主干开发，美团、字节也陆续跟进。不是因为他们喜欢谷歌，而是微服务架构逼的——几十个服务各自独立部署，GitFlow的分支模型根本管不过来。

但转型有门槛。Trunk-Based Development的前提是全自动化测试覆盖，很多团队的测试代码比业务代码还少。功能开关也需要基础设施，否则就是埋雷。

所以现实是分层分布的：初创团队用GitHub Flow，中等团队在GitHub Flow和主干开发之间摇摆，真正全员主干开发的仍是少数。GitFlow没有完全消失，在嵌入式软件、合规要求严格的金融领域还能见到——那些地方发布周期以季度计，GitFlow的"重型结构"反而匹配。

工具永远在适配组织，而不是反过来。当你的部署频率从季度变成小时，分支策略自然会跟着变。

你们团队现在用哪种模式？最近一次合并冲突解决了多久？