GitHub 原生堆叠式 PR 改善评审瓶颈

过去几年，软件开发生命周期发生了巨大变化。Agentic 开发工作流，以及最近 Anthropic 团队提出的 loop engineering 等理念，将工程生产力提升到了前所未有的水平。过去需要一个 Sprint 才能完成的功能，如今一个下午就能发布。

但问题在于：写代码变快了，代码审查却没有。

对于使用 GitHub 的团队来说，这造成了一个令人头疼的瓶颈。一个大型功能以一个巨大的 Pull Request 提交，审查者盯着 1,500 行的 diff，叹口气，然后把它移到“稍后处理”。与此同时，作者也被卡住了。如果不手动处理多个分支并反复 rebase，他们就无法在尚未审查的工作之上继续开发。结果呢？不断堆积的待办任务、受阻的开发者，以及那种再熟悉不过的“等待 PR 审查”困境。

这种痛苦其实有数据支撑。一项针对 150 万个 Pull Request 的分析发现，少于 200 行的 PR 获批速度大约快 3 倍，缺陷数量也少约 40%。一旦超过 1,000 行，审查者就会耗尽心智能力，难以发现真正的问题。

2026 年 7 月 30 日，GitHub 推出了原生解决方案：Stacked Pull Requests。目前该功能处于公开预览阶段，并正在向所有仓库逐步开放。多年来，stacked-diff 社区（Graphite、Sapling、git-branchless）一直围绕这一理念开发第三方工具。现在，它已经直接内置于 GitHub：覆盖 Web、CLI、移动端，甚至可以通过 gh-stack skill 被 Copilot 等 coding agent 使用。

什么是 Stacked Pull Request？

Stacked Pull Request 是一组有序排列的 Pull Request，其中每个 PR 都代表大型变更中一个聚焦的层次，并且每个 PR 都以它下方 PR 的分支作为目标分支。

main ← one-massive-1500-line-pr

main ← db-schema ← api-endpoints ← frontend-ui

三个小型 PR，每一个都有自己聚焦的 diff。你的团队成员可以彼此独立、并行地审查数据库层、API 层和 UI 层；当所有内容都通过审批后，只需点击一次，就能合并整个 stack。

由于它是 GitHub 的原生功能，现有的分支保护、必需检查和审查规则都会继续生效。你保护 main 分支的方式完全不需要改变。

如何操作：分步说明

下面通过构建一个真实的 stack 来了解整个过程。假设我们要发布一个“用户通知”功能，它由三个逻辑层组成：数据库 schema、API endpoint 和 UI。

需要 GitHub CLI（gh）2.90.0 或更高版本，以及 Git 2.20 或更高版本。如果尚未安装，请使用以下命令。在基于 Unix 的系统上：

sudo apt install gh

brew install gh

winget install GitHub.cli

完成 CLI 身份验证：gh auth login

你还需要一个自己有权推送的仓库（所有分支必须位于同一个仓库中，不支持跨 fork 的 stack）。

第 1 步：安装 CLI 扩展

gh extension install github/gh-stack

就这么简单。GitHub 声称，你可以在一分钟内创建自己的第一个 stack。说实话，他们并没有夸大其词。

第 2 步：初始化 stack

进入你的仓库并运行：

gh stack init

系统会提示你为第一个分支命名（这里将它命名为 notifications-db-schema）。这会创建一条跟踪记录，并基于 trunk 检出第一个分支。默认情况下，trunk 是仓库的默认分支，例如 main，但 stack 可以指向任意分支。

第 3 步：处理第一层

这里没有任何新东西——像平时一样编写代码、暂存并提交：

git add .
git commit -m "Add notifications table and model"

第 4 步：在上面添加下一层

当你准备开始下一个逻辑工作单元时，在当前分支上创建一个新分支：

gh stack add notifications-api

git add .

git commit -m "Add notifications REST endpoints"

专业提示：gh stack add -Am "message" 可以在一个步骤中暂存所有内容、提交变更并创建下一个分支，不需要分别执行 git add 和 git commit。

对 UI 层重复同样的操作：

gh stack add notifications-ui

git add .

git commit -m "Add notifications dropdown component"

现在，本地 stack 如下所示：

main ← notifications-db-schema ← notifications-api ← notifications-ui

你可以随时使用以下命令查看：

gh stack view

它会显示分支树、你当前所在的位置，以及所有关联的 PR 编号。你还可以使用 gh stack up、gh stack down、gh stack top 和 gh stack bottom 在 stack 中快速切换。

第 5 步：推送全部内容并创建 PR

gh stack submit

这会按照从父分支到子分支的顺序，将每个分支推送到远程仓库，并在 GitHub 上创建所有 Pull Request。每个 PR 都会自动设置正确的 base 分支——notifications-api 的目标是 notifications-db-schema，而不是 main——因此，审查者只会看到该特定层的 diff。这些 PR 也会自动关联成一个 stack。

之后又做了修改？只需再次运行 gh stack submit，所有内容都会随之更新。

第 6 步：独立审查每一层

在 github.com 上打开 stack 中的任意 PR，你会在合并框顶部看到一张 stack map。它会显示 stack 中的每个 PR 及其状态，并允许你一键跳转到任意一层。

对于团队来说，这正是它的魔力所在：一位团队成员可以审查 schema PR，另一位则可以同时审查 API PR。两者可以并行进行，互不阻塞，也不需要任何人在脑子里装下一个 1,500 行的 diff。

第 7 步：合并一个、部分或全部 PR

你有多种选择：

合并整个 stack：合并最上层已经准备就绪的 PR，GitHub 会在一次操作中合并它以及下方所有尚未合并的层。

合并 stack 的一部分：合并一个或多个较低层。上方的 PR 会继续保持打开状态，GitHub 会自动对它们执行 rebase 并重新设置目标分支，不需要手动完成繁琐的 rebase 操作。

分支保护和必需检查仍会约束所有最终进入 main 的内容。

合并之后，使用以下命令同步本地状态：

gh stack sync

这条命令会拉取远程内容、与 GitHub 状态进行协调、对剩余内容执行 rebase，并刷新 PR 状态。添加 --prune 可以清理与已合并 PR 对应的本地分支。

你也可以完全通过 github.com 构建 stack：只需将每个新 PR 的 base 分支设置为其下方 PR 的分支即可。GitHub 会识别这条链，甚至会显示一条推荐横幅，建议你将已经打开且相互衔接的 PR 转换成 stack。你也可以通过 GitHub 移动端应用使用 stack，Copilot 等 coding agent 则可以借助 gh-stack skill 使用它。

Stacked Pull Requests 直击 Agentic 时代真正的瓶颈：问题不在于编写代码，而在于如何安全地完成审查与合并。与其寄希望于审查者不断扩展自己的注意力，以应对越来越庞大的 diff，现在工具本身已经能够强制拆分变更，并默认支持并行审查。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。