GitHub 公开预览 Stacked Pull Requests 功能

GitHub 宣布公开预览 Stacked Pull Requests 。该功能原生支持将大型软件变更拆分为多个比较小的相互依赖的拉取请求，从而可以分别进行审查和合并。该功能旨在解决现代软件开发中一个长期存在的难题：如何在代码生成速度不断提升（尤其是借助 AI 辅助开发的情况下）与人类代码审查人员有限的处理能力之间取得平衡。

现在，开发人员不用再提交包含数百或数千行代码的单个拉取请求，而是可以将工作拆分为一系列比较小的拉取请求，每个请求都基于前一个请求进行构建。审查人员可以单独评估每一个逻辑变更。这不仅减轻了认知负担，还使得开发工作能够持续进行，不用等待整个功能完成后才开始审查。GitHub 的实现还保留了现有的分支保护规则、审查工作流和合并策略，使得分层开发成为现有代码库实践的自然延伸，而不需要单独的工作流。

本次公告的发布时机反映了软件行业正在发生的广泛转变。如今，AI 编码助手能在几分钟内生成大量可直接投入生产的代码，但代码审查仍然主要由人工完成。随着开发速度的加快，审查质量有可能会成为软件交付的主要瓶颈。

Stacked Pull Requests 试图通过缩小审查范围（而非加快审查本身）来解决这一问题。它不再要求审查者同时理解数十项互不相关的更改，而是让每个拉取请求代表一个单一的逻辑步骤，例如引入新的 API、更新数据库架构或实现特定的业务功能。审查范围越小，通常越容易理解、越容易验证，也越不容易因为某些更改疏漏而引入缺陷。

除了改善代码审查外，Stacked Pull Requests 还能优化开发流程。通常，大型功能需要一些基础性工作，而这些工作往往会阻碍后续开发，直到审查完成为止。借助分层变更，开发人员可以在早期工作的基础上继续开发，同时审查人员可以单独评估每一层。

这使得提交者和评审者之间能够进行更连贯的协作，同时减少了对长期存在的大型功能分支的需求——这类分支往往容易出现合并冲突和代码过时的问题。此外，这种做法还鼓励开发者将软件变更视为渐进式的架构改进，而非整体性的功能交付；而这种实践已被证实能降低部署风险并加快反馈速度。

尽管在 GitHub 上尚属新事物，但“分层开发”绝非新概念。Meta 通过其内部开发工具推广了“分层差异比较”（stacked diffs），而 Graphite 和 Sapling 等公司也围绕类似的工作流构建了专用的工具。此前，许多 GitHub 团队一直依赖第三方工具或手动分支管理来实现类似的效果。

通过将该功能直接集成到 GitHub 中，微软消除了此前阻碍其广泛采用的大部分运维负担。现在，团队可以利用熟悉的 GitHub 工作流来创建、审查、更新和合并相互依赖的拉取请求，而且不需要在工程环境中引入额外的工具。

近期研究进一步印证了这一挑战。一项针对智能编码工具早期采用情况的分析发现，尽管由人工智能生成的拉取请求正变得越来越普遍，但成功的集成仍然高度依赖于人工监督。大多数项目在合并前，仍然需依靠一位经验丰富的审查者来验证智能编码工具生成的代码。另一项针对从业者观点的研究得出结论：代码审查已经成为决定人工智能是提升还是降低软件质量的关键控制点。因此，随着智能编码工具能力的不断提升，结构化的审查流程变得愈发重要。

包括 Graphite 在内的多家公司已经构建了专门用于分层开发的平台，而为了降低交付风险，现代工程组织越来越重视小粒度拉取请求、主干开发、持续集成和增量部署。

这一趋势也与 GitHub 自身最近推出的创新功能相契合，其中包括：Copilot 编码助手、CodeQL 增强功能、构建签名认证、基于 MCP 的密钥扫描，以及扩展的 AI 辅助开发工作流。所有这些举措表明，软件工程的未来将不再主要依赖于生成更多代码，而是更多地依赖于创建能够让人类与 AI 进行安全、透明地大规模协作的工作流。

随着 AI 不断加速软件开发的进程，诸如 Stacked Pull Requests 这样的功能可能不再仅仅是一个便利的工具，而是成为一种必要的手段。在代码生成日益自动化的时代，审查、理解并安全地集成这些代码的能力，可能会成为高绩效工程团队的核心竞争力之一。

原文链接：https://www.infoq.com/news/2026/08/github-stacked-pull-requests/