前言¶
大型功能改动往往意味着一个体积庞大的 Pull Request：审查者需要面对上千行 diff，CI 跑很久，反馈周期被拉长，合并冲突也更容易堆积。不少团队会手动把改动拆成多个有依赖关系的分支和 PR，但 rebase、对齐 base 分支、确认每层 CI 状态，这些维护成本并不低。
2026 年 7 月 30 日，GitHub 宣布 Stacked Pull Requests（堆叠 PR） 进入公测（Public Preview）。该功能把大型变更拆成有序、可独立审查的 PR 链，并在 Web、CLI、移动端及 Copilot Agent 中统一管理；审查者可以并行 review 不同层，合并时也能一键落地整栈。本文基于 GitHub 官方 Changelog 与文档，梳理这一功能的核心机制与上手方式。
说明：堆叠 PR 目前处于公测阶段，功能与 API 可能调整；Merge Queue 对堆叠 PR 的支持将在未来数周内逐步推出。
什么是堆叠 PR¶
堆叠 PR 是指同一仓库内两个及以上 Pull Request 形成的依赖链：
- 最底层（bottom）的 PR 以主干分支（通常是
main）为 base； - 其上每一层 PR 的 base 都是下一层 PR 所在的分支。
示意结构如下：
┌── feat/frontend → PR #3（base: feat/api-endpoints） ← 顶层
┌── feat/api-endpoints → PR #2（base: feat/auth-layer）
┌── feat/auth-layer → PR #1（base: main） ← 底层
main（默认主干）
每层 PR 只展示「当前分支相对下一层分支」的 diff，而不是整坨改动的累积差异。共享类型、数据库 schema 等基础改动放在较低层；依赖它们的 API、UI 逻辑放在更高层。官方文档强调一条原则：若 A 层代码依赖 B 层，则 B 必须在同一层或更低层。
为什么社区讨论热度高¶
堆叠 PR 并非全新概念——Graphite、ghstack 等工具早已在 GitHub 生态里实践类似工作流。此次 GitHub 原生支持后，几个痛点被直接解决：
- 分支维护：依赖链上的 rebase 由 GitHub 服务端或
gh stackCLI 自动级联处理，合并底层 PR 后，上层分支会自动 rebase 并 retarget。 - 规则与 CI：过去链式 PR 往往只有最底层能完整触发 branch protection 和 CI；现在 stack 中每一层都会执行与 base 分支（通常是
main）相同的保护规则和 PR 触发的 Actions 检查。 - 审查上下文：Web 端 PR 顶部会显示 stack 图标与 stack map，审查者能清楚看到当前层在整个改动中的位置。
在 AI 辅助编码普及的背景下，这一功能也被官方明确对标「高产出开发」场景：Agent 完成一个任务后立刻在上一层继续下一个任务，每层对应一个 PR，避免把不相关改动揉进同一分支。
Next.js 负责人 Tim Neutkens、jQuery 作者 John Resig 等在 GitHub 公告中均提到，堆叠 PR 帮助团队在保持小步审查的同时推进大功能；John Resig 还特别提到配合 gh CLI 与 Agent skill 可以一次性将多层 PR 送入 Merge Queue。
在哪里能用¶
根据官方文档，堆叠 PR 目前支持：
| 入口 | 说明 |
|---|---|
| GitHub 网站 | stack map、层级导航、一键合并整栈 |
| GitHub CLI | gh stack 扩展，负责本地创建、rebase、提交 |
| GitHub Mobile | 移动端查看与操作 stack |
| Webhooks / REST / GraphQL | 自动化集成，payload 含 stack 对象 |
| Copilot 等 Agent | 通过 gh-stack skill 驱动 CLI |
暂不支持：GitHub Desktop；跨 fork 的 stack（所有分支须在同一仓库）。
快速上手：gh stack CLI¶
环境要求¶
- GitHub CLI（
gh）2.90.0 或更高，Git 2.20 或更高 - 已执行
gh auth login完成认证 - 对目标仓库具备 push 权限
安装扩展¶
gh extension install github/gh-stack
若要在 Copilot 等 AI Agent 中使用，可额外安装 skill：
gh skill install github/gh-stack
创建第一个 stack¶
- 在仓库目录初始化 stack，CLI 会创建跟踪记录并生成第一个分支：
gh stack init
- 在当前层正常写代码、提交：
git add .
git commit -m "添加 auth 中间件"
- 开始下一个逻辑单元时，在 stack 顶部新增分支：
gh stack add feat/api-routes
# 继续开发并 commit ...
- 推送所有分支：
gh stack push
- 创建 PR 并在 GitHub 上链接为 stack：
gh stack submit
第一条 PR 的 base 是 main，后续每层 PR 的 base 为下一层分支。审查者每层只看到自己负责的那部分 diff。
- 随时查看 stack 全貌：
gh stack view
常用命令速查¶
| 命令 | 作用 |
|---|---|
gh stack add -Am "MESSAGE" |
暂存、提交，并在需要时创建新层 |
gh stack sync |
拉取远端、rebase、推送并同步 PR 状态 |
gh stack rebase |
对 stack 执行级联 rebase |
gh stack merge |
合并一层或多层 stack PR |
gh stack checkout <PR号> |
按 PR 号切换 stack 中的分支 |
gh stack unstack |
解除 stack 关联 |
Web 端审查与合并¶
打开 stack 中的任意 PR，页面顶部会显示层级编号与 stack map，可一键跳转到其他层。不同审查者可以并行 review 不同层，互不阻塞。
合并规则要点：
- 必须从底层向上合并；
- 合并顶层 PR 时，其下所有未合并层会一并落地；
- 若只合并中间某层，该层及以下合并，上层 PR 保持打开并自动 retarget；
- 支持 merge commit、squash、rebase 三种合并方式，且与 Merge Queue 兼容（支持正在逐步 rollout）。
与 Merge Queue、Copilot 的关系¶
Merge Queue 用于在合并前排队跑 CI、避免主干冲突；官方表示 stack 的 Merge Queue 支持正在分阶段推出。John Resig 在公告中的用例是「一次性将 5 个堆叠 PR 送入 merge queue」，说明目标场景是：多层改动各自通过审查与检查后，作为整体有序进入主干。
Copilot 侧则通过 gh-stack skill 让 Agent 理解 stack 语义——创建分支链、push、submit、rebase 等操作都可以被 Agent 调用，适合 AI 连续产出多步改动的场景。GitHub 文档也提供了「Stack AI-generated code in pull requests」教程，指导如何把 Agent 产出组织成 stack。
使用时的注意点¶
- 公测阶段：API 有更新，若通过 REST API 合并 stack，需使用支持 stack 的新版 merge API（文档标注 API 版本
2026-03-10）。 - 仓库范围：不支持 fork 仓库之间的 stack。
- 拆分粒度：每层应是可独立审查的逻辑单元；切换前后端、核心逻辑与测试等「不同关注点」时适合开新层。
- ** rollout 节奏**：功能在未来数天内向所有仓库开放；Merge Queue 集成需等待后续更新。
小结¶
GitHub 堆叠 PR 把「大 PR 难审、链式分支难维护」这一老问题收进了原生工作流：小层并行审查、规则与 CI 逐层生效、合并时一键落地整栈，rebase 由平台托管。对习惯 Graphite 等第三方工具的团队，这是一次「不用换平台也能 stack」的选项；对正在用 Copilot 加速产出的团队，则提供了一条把 Agent 产出结构化入库的路径。
若你所在团队正被巨型 PR 拖慢节奏，可以先 gh extension install github/gh-stack，用一个小功能试水 stack 拆分，再在 Web 端体验 stack map 与整栈合并。公测期间欢迎在 GitHub 的 stacks discussion 中反馈使用体验。
