前言¶
大型功能改动往往意味着一个体积庞大的 Pull Request：审查者面对上千行 diff 容易走马观花，作者则要手动维护多条依赖分支、反复 rebase，CI 与分支保护规则还常常只对栈底 PR 生效。Stacked Pull Requests（堆叠 PR）是业界长期探索的解法——把一次大变更拆成有序、有依赖关系的小 PR 链，逐层审查、按需合并。
2026 年 7 月 30 日，GitHub 在 Changelog 中宣布 Stacked Pull Requests 进入公测（Public Preview），并在官网、CLI、移动端及 API 层面提供原生支持。配套开源扩展 github/gh-stack 与 Copilot 可用的 gh-stack skill 一并发布。Next.js、TED、WHOOP 等团队已在预览期使用，Hacker News 与开发者社区讨论热度较高。本文基于官方 Changelog、文档与 gh-stack 仓库说明，梳理这一能力是什么、解决什么问题，以及如何上手。
什么是堆叠 PR¶
堆叠 PR 指同一仓库内两个及以上相互依赖的 Pull Request，形成一条「自下而上」的分支链：
┌── 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 的目标分支是主干（通常是
main，也可以是 release 分支等任意 trunk）。 - 上一层 PR 的目标分支是下一层 PR 所在的分支，而非直接指向
main。 - 每个 PR 只展示「本层相对下一层」的 diff，审查者看到的是聚焦、可消化的小改动。
- 依赖顺序：若 A 层代码依赖 B 层，则 B 必须在同层或更低层；切换关注点（例如从后端切到前端、从核心逻辑切到测试）时，应新建一层分支。
官方文档强调的核心原则：不必等底层 PR 合并后再开上层 PR，可以在底层仍 open 的状态下继续往上叠，从而在大项目推进中保持开发节奏。
为何此时受到关注¶
堆叠 diff 并非新概念，Graphite、Sapling、git-branchless 等工具此前已在 GitHub 生态外提供类似工作流。GitHub 将其做成平台原生能力，主要回应三类现实痛点：
1. 大型 PR 审查瓶颈¶
单个 PR 过大时，审查慢、易漏检、易 stale 并产生合并冲突。Next.js 负责人 Tim Neutkens 在官方公告中称，团队使用堆叠 PR 数月，能在交付大功能的同时保持每层改动足够小、便于 review。
2. AI 辅助开发带来的新压力¶
TED CTO Andy Merryman 提到，AI 显著提升了开发产出，但 PR 体积随之膨胀，审查成为新瓶颈。堆叠 PR 把大 diff 拆成语义清晰的小块，有助于提高审查速度与准确性。GitHub 文档也明确写到：当 Agent 连续完成多个有依赖的任务时，可直接映射为「一层 PR 对应一个任务」的栈结构。
3. 手工维护依赖分支的成本¶
在没有原生支持时，拆分依赖 PR 意味着：手动 rebase 同步、CI 可能只跑栈底、中间层 PR 脱离上下文难以审查。GitHub 堆叠 PR 将整条链视为关联单元，同时保留每层的小粒度 diff，并自动处理级联 rebase 与 base 分支重定向。
平台原生能力一览¶
公测版本在以下入口可用（官方文档核实）：
| 入口 | 说明 |
|---|---|
| github.com | PR 页顶显示栈图标与层数；合并框内有 stack map，可一键跳转各层 |
| GitHub CLI | gh stack 扩展，管理本地分支、推送、提交 PR |
| GitHub Mobile | 移动端同样支持栈视图与操作 |
| Webhooks / REST / GraphQL | pull_request 事件含 stack 对象；REST 可列出、创建、扩展、解散栈 |
| Copilot 等 Agent | 通过 gh-stack skill 调用 CLI 工作流 |
当前限制（文档明确标注）：
- 所有分支必须在同一仓库，不支持跨 fork 堆栈。
- GitHub Desktop 暂不支持。
- 功能处于 Public Preview，接口与行为可能调整。
- Merge Queue 对堆叠 PR 的支持将在未来数周内逐步 rollout，并非所有仓库立即可用。
审查与合并机制¶
独立审查、并行推进¶
打开栈中任意一层 PR，审查界面仅显示该层 diff；顶部 stack map 展示整栈结构与各层状态。不同审查者可同时 review 不同层，互不阻塞。
分支保护与 CI¶
合并要求以栈底 PR 的 base 分支（通常为 main）为准，但每一层都会执行分支保护规则（如 CODEOWNERS）以及针对默认分支触发的 CI，而非只有栈底跑检查。这解决了以往「中间层 PR 质量状态不透明」的问题。
合并方式¶
合并必须自底向上，支持三种策略：
- 整栈合并：合并栈顶 PR，其下所有未合并层一并落地（merge commit、squash、rebase 均支持）。
- 部分合并：合并栈中某一中间层，该层及以下合并，上方层保持 open 并自动 rebase、重定向 base。
- 单层合并：只合并栈底或部分底层，按需逐步推进。
合并结果与逐层单独合并的提交历史一致。若通过 API 合并，需使用支持堆栈的新 merge API（文档 API 版本 2026-03-10 起）。
自动 rebase¶
rebase 是堆栈工作流中最易出错的环节。GitHub 支持在 PR 页面触发服务端级联 rebase；本地则可用 gh stack 扩展执行级联 rebase。合并栈底后，剩余分支会自动 rebase，下一层 PR 的 base 会指向新的主干位置。
用 gh-stack 快速上手¶
官方 CLI 扩展仓库：https://github.com/github/gh-stack（截至写作时 GitHub 上 star 数已逾数百）。要求已安装 GitHub CLI（gh v2.0+）。
1. 安装扩展与 Agent Skill¶
# 安装 gh stack CLI 扩展
gh extension install github/gh-stack
# 可选：为 Copilot 等 Agent 安装 gh-stack skill
gh skill install github/gh-stack
2. 创建第一个栈¶
典型工作流如下：
# 初始化栈（创建并 checkout 第一层分支）
gh stack init
# 在第一层上完成 commit ...
# 在栈顶再叠一层
gh stack add api-endpoints
# 继续 commit，按需 gh stack add ...
# 推送所有分支
gh stack push
# 查看栈结构
gh stack view
# 为各层创建并关联 PR
gh stack submit
也可非交互式指定分支名：
gh stack init feature-auth feature-api feature-ui
栈元数据保存在本地 .git/gh-stack（JSON，不提交到仓库），用于跟踪分支顺序；gh stack init 会自动启用 git rerere，以便 rebase 冲突解决可被记住。
3. 常用导航命令¶
gh stack 中 up 指向远离 trunk 的方向（栈顶），down 指向靠近 trunk 的方向。其他命令包括 checkout、sync（拉取 trunk 并级联 rebase）、restack（变基整栈）等，完整说明见仓库 README。
与 Merge Queue、Copilot 的关系¶
Merge Queue：GitHub 公告写明，堆叠 PR 的 Merge Queue 支持正在分阶段推出。John Resig 在公告中提及，可将 5 个堆叠 PR 一次性送入 merge queue 合并——这依赖该能力在目标仓库已启用。
Copilot Agent：通过 gh-stack skill，Agent 可遵循与 CLI 相同的分支顺序创建栈、提交 PR，避免把多个无关联任务塞进单一巨大 diff。这与 GitHub 文档中「Agent 完成一个任务后基于其继续下一任务」的描述一致。
公测 rollout 与反馈渠道¶
根据 2026-07-30 官方 Changelog：
- 堆叠 PR 公测将在未来数天内向所有仓库逐步开放。
- Merge Queue 集成将在未来数周内逐步推出。
- 详细用法见文档：About stacked pull requests；反馈可在 GitHub 的 stacks discussion 中提交。
小结：值不值得现在试¶
若你或团队经常面对「一个大 PR 没人敢审」或「AI 产出快、审查跟不上」的情况，GitHub 原生堆叠 PR 值得在公测期试点：工作流与现有 review、checks、分支保护兼容，CLI 与 Agent skill 降低了建栈成本。若团队已深度依赖 Graphite 等第三方工具，可先并行对比再决定是否迁移；跨 fork 协作、Desktop 用户则需等待后续支持或继续沿用现有方案。
无论如何，把大变更拆成有依赖顺序的小 PR、逐层审查、整栈一键合并——这条思路已被 GitHub 写入平台默认能力，值得纳入下一次大型改动的分支策略考量。
