GitHub 推出分层拉取请求以优化代码审查

GitHub 推出了名为分层拉取请求（Stacked Pull Requests）的新功能，旨在简化大规模代码变更的审查流程。截至 2026 年 8 月 4 日，该功能目前处于私人预览阶段。分层拉取请求允许开发人员将庞大的拉取请求分解为较小且集中的层次，可以独立审查和合并。这种方法不仅减少了审查者的疲劳，还加快了反馈和部署的速度。

传统上，开发人员面临一个痛苦的选择：提交一个庞大的拉取请求，难以有效审查，或者手动管理一系列较小的拉取请求，这往往导致冲突和管理上的麻烦。分层拉取请求通过引入依赖链的结构消除了这一难题。堆栈中的每个拉取请求都基于其下方的请求构建，因此审查者只需关注每一层的增量更改。

分层拉取请求的工作原理

GitHub 的工作流程将大型功能划分为离散的层次，每一层都聚焦于单一的关注点。例如，一个新的产品搜索功能可能被分解为：

• 层 1：数据模型设置
• 层 2：API 创建
• 层 3：后端集成
• 层 4：前端用户界面

每一层依赖于其前一层，使审查者能够专注于较小、逻辑分组的更改。GitHub 还通过 gh-stack 扩展提供 CLI 支持，帮助开发人员直接在终端中创建、管理和变基这些堆栈。

这一过程还与 GitHub 的 CI/CD 工作流无缝集成。较低层次的更改会自动级联到整个堆栈，促使依赖层的更新和重新验证。这确保了每一层都保持稳定并准备好进行审查。

分层拉取请求中的代理与自动化

随着 AI 编码代理的日益普及（Gartner 预测到 2028 年，软件开发生命周期的生产力将提高 50%），GitHub 已调整分层拉取请求以适应这些代理。这些代理可以被训练为将任务分解为可堆叠的层次，处理验证，甚至管理堆栈内的变基冲突。这种自动化尤其能够减少大型团队在交付复杂功能时的人为瓶颈。

为什么这很重要

分层拉取请求并不是一个全新的概念；类似的工作流程早已被 Phabricator、Graphite 和 Git Town 等工具推广。然而，GitHub 的实现因直接将工作流程集成到其平台以及现有的拉取请求和 CI 系统而显得尤为突出。这可能使分层拉取请求成为已经使用 GitHub 的团队的默认选择，尤其是在该功能成熟并脱离私人预览阶段后。

对于开发人员来说，益处显而易见：较小且有针对性的审查带来更高质量的反馈、更快的合并速度，以及在部署过程中更少的最后一刻意外。对于组织而言，这种结构化方法可以提高开发速度，并减少由未充分审查的代码导致的昂贵延误。

接下来是什么？

尽管分层拉取请求目前处于私人预览阶段，GitHub 预计将在未来几个月内推出更广泛的可用性。该公司还与 Devin 等工具合作以扩展支持，进一步将这一工作流程嵌入到开发者生态系统中。随着自动化和 AI 集成的改进，分层拉取请求可能成为现代软件交付管道的基石。

有兴趣尝试分层拉取请求的开发人员可以查阅 GitHub 的文档以获取设置指南和 CLI 命令。随着生产力的提升，这一功能可能会显著改变团队处理大规模编码项目的方式。