GitHub 正式推出堆叠 PR（Stacked PRs） 新功能，旨在简化大型拉取请求的审核与管理流程，让代码合并流程推进效率更高。
目前堆叠 PR 已开启私密预览版测试。该功能支持将一个拉取请求基于上一个拉取请求构建，形成层级堆叠结构。堆叠中的每一个 PR 都可单独审核与合并，前提是其下方所有 PR 已完成合并；同时也支持整组堆叠 PR 一次性合并。
堆叠 PR 具备多项优势，最直观的作用是引导开发者拆分出更小粒度的 PR，大幅降低审核难度。官方文档说明：堆叠结构里的每个分支，都应对应独立、逻辑完整的工作单元，支持单独审核。
在传统开发模式下，很难做到这一点。开发者往往需要基于尚未合并到主分支的前期代码继续开发新功能。如果等待每一小段代码逐一审核合并，会严重拖慢开发进度，因此开发者通常会在独立分支持续开发，直至完整功能完工。最终就会生成涉及大量文件改动的巨型 PR，给代码审核带来极大困难。
GitHub 堆叠 PR 的使用与行业渊源
堆叠 PR 对 GitHub 而言是全新功能，但在其他代码管理与审核系统中早已普及，这类机制常被称作堆叠差异（stacked diffs）。最知名的同类工具是 2007 年由 Facebook 开发者埃文・普里斯特利与卢克・谢泼德开发的 Differential。普里斯特利表示：“我当时耗费大量时间等待代码审核，这也是我开发这款工具的核心初衷。”
后续 Differential 成为 Facebook 开发工具套件 Phabricator 的核心组件，并于 2011 年开源发布。
开源版 Phabricator 已于 2021 年停止迭代，但其衍生分支 Phorge 至今仍在持续维护更新。
启用堆叠 PR 后，开发者工作流会和传统模式有明显差异。堆叠结构最底层的 PR，通常直接基于主分支创建，而非独立开发分支。2006 至 2016 年任职于 Facebook 的工程师杰克逊・加巴德曾发布详细解读：习惯了 Phabricator 堆叠差异工作流的开发者，大多十分认可这种模式，并会在后续工作中主动寻求同类工具支持。
该功能在黑客新闻平台引发热议，整体评价偏向正面。不过有开发者提出不同看法：“我并不认为这款命令行工具是刚需，近几年 Git 原生新增的部分功能，已经可以实现同类效果。” 开发者所指的命令行工具，是 GitHub 专为该功能推出的扩展工具 gh stack。
即便如此，将堆叠机制深度整合进 GitHub 平台仍是一次重大升级，配套命令行工具也进一步简化了操作门槛。负责该功能研发的 GitHub 工程师萨明・卡里姆表示：“命令行工具完全可选，用户仅通过网页界面，也能完整创建堆叠 PR。”
GitHub 还计划为该功能融入 AI 能力。卡里姆在领英发文称：“如今开发的瓶颈早已不是编写代码，而是代码审核，堆叠 PR 正是为解决这一痛点而生。” 他同时提到，这款堆叠命令行工具也专门适配了 AI 智能代理的调用场景。
苏公网安备32021302001419号