GitHub刚刚上线的Stacked PRs功能，直接把Facebook 2007年的内部工具搬上了全球4000万开发者的桌面。一个被Meta工程师"走到哪带到哪"的工作流，为什么现在成了GitHub的优先级？
「堆叠」到底是什么：把一坨代码拆成可独立审查的薄片
Stacked PRs（堆叠式拉取请求）的核心机制很简单：后一个PR可以基于前一个PR创建，形成一条依赖链。每个PR都能单独审查、单独合并，前提是它下面的所有PR必须先合并。也可以一键合并整条链。
GitHub官方文档的表述很克制："堆栈中的每个分支应代表一个离散的、可独立审查的逻辑工作单元。"
但这句话背后是一个被抱怨了十几年的痛点。开发者通常不会在等代码审查时干等着——他们会继续写新功能，而新功能又依赖还没合并的旧代码。结果就是：一个功能做完，攒出一个改动几十上百个文件的大PR，审查者直接崩溃。
Stacked PRs用依赖链把大功能切成小片。你可以基于未合并的分支继续开发，但提交时保持逻辑隔离。审查者每次只看一个最小变更集，反馈周期从"等一周"变成"等几小时"。
Meta遗产：一个被工程师"绑架"到下一家的工具
这个模式对GitHub是新的，对行业不是。2007年，Facebook工程师Evan Priestley和Luke Shepard做了Differential，专门解决"等代码审查等到地老天荒"的问题。Priestley的原话是：「我花了大量时间等待代码审查，这是构建这个工具的主要动机。」
Differential后来成为Phabricator套件的一部分，2011年开源。2021年Phabricator停止维护，但分叉项目Phorge至今活跃。
真正说明问题的是工程师用脚投票。Jackson Gabbard（2006-2016年在Facebook工作）写过一篇详细解释：「用过Phabricator的'堆叠diff'工作流的人，普遍非常喜欢它，走到哪都会寻找类似工具。」
这不是怀旧。Stack Overflow的2023年开发者调查显示，代码审查延迟是生产力损耗的第二大来源，仅次于技术债务。GitHub这次不是创新，是补课——补一个被验证了17年的需求。
AI时代的算盘：当写代码不再是瓶颈
GitHub产品负责人Sameen Karim在LinkedIn上的表态值得玩味：「瓶颈不再是写代码——而是审查代码。堆叠式PR能解决这个问题。」
这句话的上下文是Copilot。GitHub的AI编程助手已经让代码产出速度翻倍，但审查产能没有同步提升。一个工程师一天能写出的代码量，可能超过团队能审查的量。Stacked PRs把审查单元变小，本质是用流程优化对冲AI带来的审查压力。
Karim还澄清了一个关键点：「命令行工具完全是可选的，你可以纯用网页界面创建堆叠式PR。」这针对的是Hacker News上的质疑——有开发者认为Git原生的部分新功能已经能覆盖这个场景，不需要专门的gh stack命令行扩展。
但GitHub的选择是把工作流做进平台层。CLI只是降低使用门槛，真正的价值在于GitHub原生支持了依赖链的可视化、状态同步和批量操作。这是第三方工具或Git原生功能无法提供的体验闭环。
为什么现在？平台竞争进入「工作流深度」阶段
GitLab在2023年推出了类似功能Merge Trains，Bitbucket也有实验性的堆叠PR支持。代码托管平台的竞争已经从"能不能存代码"转向"能不能让团队跑得更快"。
Stacked PRs的推出时间点也很微妙。GitHub在2024年经历了多次服务中断，企业客户对稳定性的焦虑在上升。用功能深度对冲可靠性质疑，是平台产品的常见策略。
更深层的变化是远程协作的固化。2020年前的代码审查很多是"走到同事工位看一眼"，现在异步审查是默认状态。Stacked PRs把异步流程设计得更顺滑，是对分布式团队需求的回应。
一个细节：私有预览（private preview）的门槛说明GitHub还在观察企业级使用场景。大规模团队的堆叠链可能长达十几个PR，合并顺序冲突、回滚复杂度都会指数级上升。这些边缘 case 的打磨，决定了这个功能能不能从"好用"变成"默认启用"。
开放提问
Stacked PRs解决的是审查效率，但它会改变代码所有权的分配逻辑吗？当一个大功能被拆成五个小PR，谁来对最终集成结果负责？GitHub把Meta的内部实践产品化，但Meta的工程师密度和代码文化，能直接平移到普通团队吗？
热门跟贴