GitHub抄了Facebook15年前的作业，代码审查要变天

2024年，全球开发者每天在GitHub上创建超过100万个拉取请求。但一个老问题始终没解决：大需求拆不动，小改动等不起。现在GitHub终于出手了——不是发明新东西，而是复活一套15年前就被验证过的 workflow。

Stacked PRs到底是什么

简单说，就是让一个拉取请求（pull request）可以基于另一个拉取请求创建，形成"堆栈"。栈里的每个请求都能独立审查、独立合并，前提是它下面的请求必须先合并。也可以一次性合并整个栈。

官方文档的表述很克制："栈中的每个分支应代表一个独立的、逻辑完整的工作单元，可被独立审查。"

但懂行的人知道这句话的分量。它直指一个困扰行业多年的痛点：开发者想持续写代码，但新代码依赖的代码还没被合并到主分支。等审查太慢，不等就得在一个分支里攒大招，最后端出一个改动几十个文件的巨型请求——审查者崩溃，出bug的概率飙升。

Stacked PRs给的是第三条路：边写边拆，拆完还能保持依赖关系。

这不是新发明，是Facebook的遗产

GitHub这次毫不讳言灵感来源。2007年，Facebook工程师Evan Priestley和Luke Shepard做了套叫Differential的工具。Priestley的原话是：「我当时花了大量时间等代码审查，这是做这套工具的主要动力。」

Differential后来成为Phabricator套件的一部分，2011年开源。2021年Phabricator停止开发，但fork出来的Phorge至今仍在维护。

在Facebook工作过10年的Jackson Gabbard写过一篇详细解释，他的观察很直接：「用过Phabricator堆叠式diff workflow的人，一般都会爱上它，换工作后还会到处找类似工具。」

这种用户忠诚度在开发者工具里极其罕见。想想看，一个2007年的workflow，到2024年还能让GitHub专门做个功能来"致敬"，本身就很说明问题。

GitHub的AI算盘

负责这个功能的Sameen Karim在LinkedIn上放了句狠话：「瓶颈不再是写代码——是审查代码。堆栈能解决这个问题。」

这句话值得拆解。GitHub Copilot已经让代码产出速度大幅提升，但审查带宽没有同比例增长。一个团队10个人，可能只有2-3个资深工程师能审核心模块。产出快了，审核慢了，队列越积越长。

Stacked PRs的解法是结构性分流：把一个大需求切成5个小块，5个审查者可以并行工作，不再堵在那2-3个核心人员身上。配合GitHub正在推的AI审查辅助，理论上能把审查吞吐量拉上去。

Karim还澄清了一个关键点：「命令行工具完全是可选的，你可以纯用网页界面创建堆叠式拉取请求。」这针对的是Hacker News上的质疑——有开发者说Git近几年的新功能已经能原生支持类似操作，没必要专门做个gh stack命令行扩展。

但GitHub的选择很务实：内置降低门槛，CLI留给重度用户。毕竟，能让几百万人无摩擦地用上，比让几万人用得爽更重要。

为什么现在？为什么是这个功能？

时间线很有意思。Phabricator 2021年停止开发，GitHub 2024年推出Stacked PRs。中间这3年，行业里冒出一堆替代方案：Git town、Spr、Graphite……都在做类似的事。这说明需求真实存在，但分散的工具没法形成标准。

GitHub的入场意味着两件事。第一，堆叠式workflow从"小众高级技巧"变成"平台原生能力"，学习成本骤降。第二，竞争对手（GitLab、Bitbucket）必须跟进，否则企业客户里那批Phabricator老用户会被虹吸。

更深一层看，这是GitHub对"AI时代开发流程"的一次下注。写代码的边际成本在下降，协作的边际成本反而在上升。Stacked PRs解决的不是技术问题，是组织问题——怎么让10个人异步协作，而不互相阻塞。

Hacker News上的讨论总体正面，但有一条评论很尖锐：「我不太明白这个命令行的必要性，Git近几年加的功能已经能原生支持了。」

这种声音会长期存在。但历史经验是：基础设施的胜负不取决于"能不能做"，而取决于"好不好用、多少人用"。Git的rebase功能2005年就有了，但GitHub的Pull Request界面让分支协作普及到了百万开发者。这次可能也一样。

一个被验证15年的workflow，能改变什么？

Stacked PRs的上线，本质上是一次"工程文化"的平台化。Facebook用Phabricator时期形成的习惯——小步快跑、持续审查、依赖显式化——现在可以被任何团队低成本复制。

这对中国开发者的直接意义是：如果你在用GitHub Enterprise或计划迁移，审查流程的改造窗口已经打开。不需要说服团队换工具，不需要维护额外的命令行工具，开箱即用。

但更值得观察的是GitHub的下一步。Karim的话留了口子：AI审查+堆叠式PR，会不会催生新的协作模式？比如AI先过一遍栈底部的请求，人类只审关键节点？或者栈的自动重组，根据审查者负载动态调整拆分粒度？

Phabricator的故事告诉我们：好的workflow有极强的生命力，能跨越公司、跨越十年。但它也告诉我们：工具会死，习惯会迁移。GitHub这次不是创新，是收编——把被验证的东西变成基础设施，让下一代开发者以为"本来就该如此"。

最后一个问题留给你：如果你的团队明天开始用Stacked PRs，最大的阻力会来自技术，还是来自"我们一直都是这么做的"？