打开网易新闻 查看精彩图片

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

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

但严谨是有代价的。

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

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

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

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

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

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

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

打开网易新闻 查看精彩图片

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

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

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的"重型结构"反而匹配。

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

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