前言¶
大型功能一次改完、开一个巨型 Pull Request，是不少团队都踩过的坑：Reviewer 对着几千行 diff 望而却步，CI 跑一轮就要半天，中间任何一层被 block，整条分支链都要手动 rebase。Stacked Pull Requests（堆叠 PR）的思路并不新——把大改动拆成一串有依赖关系、各自可审查的小 PR——但过去多半要靠 Graphite、Sapling 等第三方工具，或者自己维护分支基线。
2026 年 7 月 30 日，GitHub 在 Changelog 中宣布 Stacked Pull Requests 进入 Public Preview（公测），并配套开源 CLI 扩展 github/gh-stack。堆叠 PR 不再是「插件生态里的高级玩法」，而是写进 GitHub 原生 PR 流程的能力：Stack Map UI、一键合并整栈、与 Branch Protection / Merge Queue 联动，都可以在官方文档里查到。本文基于 GitHub 官方 Changelog、文档与 gh-stack 仓库 README，梳理这项功能解决什么问题、怎么用，以及和 Trunk-based Development 的关系。
堆叠 PR 是什么¶
官方定义里，Stack（栈） 是同一仓库内一系列 Pull Request 的有序链：最底层 PR 以 trunk（通常是 main）为 base，上一层 PR 以下一层分支为 base，依此类推。Reviewer 打开任意一层，看到的 diff 只包含该层的改动，而不是整坨功能的全部文件。
一个典型的三层栈结构如下：
frontend → PR #3（base: api-endpoints）← 栈顶
api-endpoints → PR #2（base: auth-layer）
auth-layer → PR #1（base: main） ← 栈底
─────────────
main（trunk）
这与 Trunk-based Development 并不冲突：trunk 仍是最终合入目标，堆叠 PR 只是把「从 trunk 到最终功能」的路径拆成若干可独立审查的增量层。Next.js 负责人 Tim Neutkens 在 GitHub 公告中也提到，Vercel 团队用堆叠 PR 在保持大功能交付节奏的同时，把单次 Review 粒度压小。
需要提前知道的限制（均来自官方文档）：
- 所有分支必须在同一仓库，不支持跨 fork 堆栈。
- GitHub Desktop 暂不支持堆叠 PR。
- 合并前栈内分支之间必须保持完全线性历史；trunk 前进或底层分支有新提交时，需要 cascading rebase 恢复。
2026 年 7 月公测带来了什么¶
GitHub 此次公测的核心变化，是把堆叠 PR 从「CLI 辅助 + 网页手动关联」升级为平台一等公民：
- Stack Map：PR 页面顶部展示栈结构，Reviewer 可并行审查不同层，互不阻塞。
- Branch Protection 按栈底评估：无论某层 PR 的 direct base 是哪条分支，Required Reviews、Status Checks、CODEOWNERS、Code Scanning 都按栈的 trunk 来跑。GitHub Actions 的
pull_request事件也会按栈底分支触发，无需改 workflow。 - 一键合并：合并栈顶（或任意已就绪层）时，其下方所有未合并层可原子性一并合入；若只合并较低层，上方 PR 会自动 rebase 并 retarget。
- Merge Queue 支持：整栈可按正确顺序入队；若某层被移出队列，其上所有层也会一并移除。Merge Queue 的 merge group 最大容量允许超出配置上限最多 50%，以尽量保持整栈同批合并。
- 三种合并方式均可用：Merge Commit、Squash、Rebase，整组 PR 作为一次原子操作落地。
公测 rollout 节奏：未来数天内向所有仓库逐步开放；Merge Queue 对堆叠 PR 的支持将在未来数周内分批上线。
安装 gh stack CLI¶
本地开发工作流推荐安装官方 CLI 扩展。前置条件是 GitHub CLI v2.0 及以上。
gh extension install github/gh-stack
github/gh-stack 采用 MIT 协议，仓库创建于 2026 年 2 月，截至公测公告前后已在 GitHub 上获得数百 Star。栈的元数据保存在本地 .git/gh-stack（JSON，不会提交到仓库）；gh stack init 会自动启用 git rerere，重复 rebase 时尽量复用已解决的冲突。
若使用 GitHub Copilot 等 AI Agent，还可安装配套 skill，让 Agent 熟悉堆叠 PR 工作流：
gh skill install github/gh-stack
不装 CLI 也可以：底层 Git 操作是标准流程，可直接在 github.com 或 GitHub 移动 App 上创建堆栈；Jujutsu、Sapling 等工具推送分支后，同样可用 gh stack 或网页端开栈。
快速上手：从 init 到 submit¶
下面是一个最小可用流程，命令来自 gh-stack 官方 README。
1. 初始化栈并添加层¶
# 交互式创建栈的第一层分支
gh stack init
# 在当前层之上继续叠加
gh stack add api-endpoints
# 再叠一层
gh stack add frontend
也可一次性指定多个分支，或指定非 main 的 trunk：
gh stack init --base develop feature-auth feature-api feature-ui
gh stack add 支持 -m 提交信息、-A / -u 暂存改动后再建分支，适合「改完一层立刻开下一层」的节奏。
2. 推送并创建关联 PR¶
gh stack push
gh stack view
gh stack submit
gh stack submit 会为栈内每个分支创建 PR，base 自动设为下一层分支，并在 GitHub 上建立 Stack 关联。加 --auto 可跳过交互式编辑器，适合脚本化场景。
3. 底层改动后的同步¶
Reviewer 对栈底 PR 提出修改后，需要把变更 cascade 到上层：
gh stack rebase
gh stack push
网页端也可在 Merge 区域点击 Rebase stack，由服务端执行 cascading rebase。
gh stack sync 则用于同步远程状态、清理已合并分支等日常维护。
4. 合并¶
栈内各层均满足 Branch Protection 且下方层也已就绪后，可在 GitHub 网页一键合并整栈，或使用：
gh stack merge
合并前官方要求：目标层及其下方所有层都已通过审查与 CI，且栈内历史保持线性。
与 Merge Queue、代码审查的配合¶
对启用 Merge Queue 的团队，堆叠 PR 的价值在于：John Resig 在公告中的反馈——一次性将多层 PR 送入 Merge Queue 合并，省去了逐层排队、手动 rebase base 的摩擦。
审查侧，TED CTO Andy Merryman 提到：AI 提升开发产出后，PR 体积膨胀成为新瓶颈；堆叠 PR 把 Review 拆成更小、有依赖顺序的逻辑块，反馈循环更短。WHOOP 工程师 Mayank Saini 则强调，整栈一键合并后，体验「像原生 GitHub 能力，而不是外挂工具」。
实践上可遵循几条官方隐含的最佳实践：
- 每层聚焦单一 concern：schema 变更、API、UI 分栈，Reviewer 按专长并行看不同层。
- 保持栈深度可控：Merge Queue 对超大栈可能拆成多个 merge group，层数过多会增加协调成本。
- CI 优化：workflow 可通过
github.event.pull_request.stack读取栈元数据，避免对每层重复跑全量集成测试（详见官方「Optimizing CI for stacked pull requests」文档）。
和第三方堆栈工具的关系¶
Graphite、Sapling、Jujutsu 等在本地分支管理上各有优势；GitHub 公测后，平台侧的 Stack UI、Protection 评估、Merge Queue 集成由官方接管，第三方工具仍可负责本地 workflow，再与 gh stack submit 或网页端衔接。
若团队已在 Trunk-based Development 下习惯小步提交，堆叠 PR 相当于把「小步」映射成「小 PR 链」，trunk 始终是最终归宿；若仍习惯长期 feature 分支，可先从一个三层以内的试点栈开始，熟悉 rebase 与 Protection 规则再扩大。
小结¶
2026 年 7 月 30 日起，GitHub Stacked Pull Requests 公测向全体仓库 rollout，配合 gh extension install github/gh-stack 即可在终端完成建栈、rebase、开 PR、合并。它针对的是「大 PR 难审查、多分支 rebase 地狱」这一老问题，把堆叠开发模型收进 GitHub 原生 PR、Checks 与 Merge Queue 体系。
功能仍处于 Public Preview，API 与行为可能调整；更多细节见 Stacked pull requests 文档，反馈可提交至 GitHub 官方 stacks discussion。
