GitHub Stacked PR 公开预览：gh-stack CLI、合并机制与 AI 时代的工作流

GitHubAI开发者工具

2026 年 7 月 30 日，GitHub 官方博客发布了一条让整个开发者社区炸开的更新：Stacked Pull Requests（堆叠式 Pull Request）正式进入公开预览。这个功能在 Hacker News 上拿到了 516 分，同时登上 Lobste.rs 热榜，Next.js 负责人 Tim Neutkens 和 jQuery 创始人 John Resig 都在首发日为其背书。

GitHub Stacked PRs 公开发布公告图

什么是 Stacked PR

传统代码评审的工作流是这样的：拉一个分支，改完代码，开一个 PR，等人 review，合并。但当代码变更体量很大时，这个模型就会崩溃——要么开一个巨大的 PR，reviewer 望而生畏；要么拆成多个分支，各自开 PR，然后手动管理 rebase 顺序，最终逐个合并，中间任何人推送了新提交，整条链都得重来。

Stacked PR 解决的就是这个痛点。它把一个大变更拆成一组有序的、有依赖关系的 PR 链：

text
frontend      → PR #3 (base: api-endpoints)  ← 顶层
api-endpoints → PR #2 (base: auth-layer)
auth-layer    → PR #1 (base: main)           ← 底层
─────────────────────────────────────────────
main (trunk)

每个 PR 的 base 分支指向链中它下面的那个分支，而不是直接指向 main。这样 reviewer 在看 PR #1 时，只看到 auth-layer 相对 main 的 diff；看 PR #2 时，只看到 api-endpoints 相对 auth-layer 的 diff。每一层都是一个小而聚焦的变更，可以并行 review，互不阻塞。

AI 时代的 PR 膨胀

TED 的 CTO Andy Merryman 在 GitHub 博客的引述中说了一句关键的话：AI 让他们的开发者生产力大幅提升，但这制造了一个新的瓶颈——PR 变得越来越大，大到 reviewer 难以处理。

这不是个别现象。当 AI 编码助手能在几分钟内生成数千行代码时，传统的「一个功能一个 PR」模型直接失效。一个 AI 辅助完成的特性可能横跨后端 API、数据库迁移、前端组件、测试用例四个层面，塞进一个 PR 里就是一场 review 灾难。Stacked PR 的价值在这个背景下被放大了：把 AI 生成的大批量代码拆成可管理的层次，每层独立评审，最后一次性合并。

WHOOP 的工程师 Mayank Saini 的体验更直接：一个大变更过去意味着一个没人想 review 的巨型 PR，现在变成一叠小 PR，reviewer 能真正跟上思路，而且整条链一次合并完成。

gh-stack CLI：核心工具

这次发布的核心载体是 gh-stack——一个 GitHub CLI 扩展，专门管理堆叠分支和 PR 的生命周期。

安装

sh
gh extension install github/gh-stack

需要 GitHub CLI (gh) v2.0+。同时还提供了一个 AI agent skill：

sh
gh skill install github/gh-stack

安装后，AI 编码代理（如 GitHub Copilot）就能理解 stacked PR 的概念并自动调用 gh stack 命令。

典型工作流

一个完整的堆叠 PR 工作流只需要几条命令：

sh
# 1. 初始化一个新堆叠（创建并 checkout 第一个分支）
gh stack init

# 2. 在第一个分支上写代码、提交
#    ... write code, make commits ...

# 3. 在顶层添加新分支
gh stack add api-endpoints
#    ... write code, make commits ...

# 4. 推送所有分支
gh stack push

# 5. 查看堆叠结构
gh stack view

# 6. 创建一组链式 PR
gh stack submit

gh stack submit 是最关键的命令。它不仅推送分支、创建 PR，还会在 GitHub 上自动创建一个 Stack 对象把所有 PR 串联起来。在交互式终端中，它会打开一个全屏编辑器，让你同时编辑所有 PR 的标题和描述，选择 ready-for-review 或 draft 状态，一次提交全部。

自动化 rebase

堆叠 PR 最大的维护成本是 rebase。当底层 PR 被合并或 main 分支有新提交时，上面的每一层都需要重新 rebase。gh stack 把这个过程自动化了：

  • gh stack rebase：从 trunk 开始，逐层向上级联 rebase。如果底层 PR 已合并，自动切换到 --onto 模式把提交重放到合并目标之上。
  • gh stack sync：一条命令完成 fetch + rebase + push + PR 状态同步。它还能自动检测本地和远程堆叠是否分叉，分叉时提示解决。

冲突发生时，操作暂停并打印冲突文件和行号。解决后用 gh stack rebase --continue 继续，或用 --abort 全部回退。

合并：一次点击搞定整条链

这是 stacked PR 最省心的部分。合并堆叠顶层的 ready PR 时，GitHub 会自动把它和下面所有未合并的层一次性全部合并。所有现有的 branch protection 规则和 required checks 照常生效。

sh
# 合并整个堆叠（交互式选择）
gh stack merge

# 合并到指定的 PR
gh stack merge 42

# 合并整个堆叠，不提示，用 squash
gh stack merge --yes --squash

合并是 all-or-nothing 操作：如果任何一层不能合并，全部都不合并。如果基础分支启用了 merge queue，整个堆叠会被加入队列一起处理。

GitHub Stacked PR 合并界面：点击 Merge stack 一次性合并整条链

重构：modify TUI

gh stack modify 打开一个终端交互界面，可以重构堆叠结构：

  • Drop：移除某个分支
  • Fold down/up：把分支的提交合并到上层或下层
  • Insert：插入新的空分支
  • Reorder：调整分支顺序
  • Rename：重命名分支

所有操作在预览中暂存，保存时一次性应用。

与传统工作流的对比

维度传统多分支Stacked PR
PR 粒度每个分支独立开 PR，base 都是 main每层 PR 的 base 是下层分支，diff 更小
Review 并行需手动协调谁先 review各层可并行 review，互不阻塞
Rebase 管理手动逐个 rebase，容易出错gh stack rebase 自动级联
合并顺序逐个合并，每次合并后上层需重新 rebase合并顶层，整条链一次合并
分支保护正常工作原有规则全部生效
Merge queue不支持堆叠支持（渐进推出中）

与第三方工具的关系

在 GitHub 官方支持之前，堆叠 PR 工作流已经存在多年。Graphite、git-town、Sapling（Meta 开源）、jujutsu (jj) 等工具都在不同层面解决了这个问题。gh stack 的 link 命令就专门为这些用户设计：如果你用 jj 或 Sapling 管理本地分支，可以用 gh stack link 直接把分支或 PR 号串联成堆叠，在 GitHub 上创建 Stack 对象，不需要 gh stack 的本地跟踪状态。

sh
# 用分支名创建堆叠
gh stack link feature-auth feature-api feature-ui

# 用已有 PR 号创建堆叠
gh stack link 10 20 30

# 用 PR URL 创建
gh stack link https://github.com/owner/repo/pull/10 https://github.com/owner/repo/pull/20

GitHub 的官方入场意味着这些第三方工具的差异化空间在缩小。但 gh stack 目前还没有提供 jj 或 Sapling 那样的版本控制原语（如虚拟提交、自动 rebase 冲突记忆），它更像是一个专注于 PR 层面的编排工具，把底层 git 操作的复杂性封装起来了。

限制和注意事项

公开预览阶段的功能限制：

  • Stacked PR 正在数天内逐步向所有仓库推出。不是所有仓库在发布当天就能看到。
  • Merge queue 对 stacked PR 的支持在未来几周内渐进推出，目前可能还不完全可用。
  • 合并时不支持绕过 merge 要求。GitHub 在合并运行时评估 branch protection 和 repository rules，任何不满足条件的 PR 都会导致整次合并失败。

本地元数据：堆叠状态存储在 .git/gh-stack（一个 JSON 文件，不提交到仓库）。rebase 中断状态存在 .git/gh-stack-rebase-state。这些文件是本地的，不会共享给其他贡献者。

git rerere 自动启用：gh stack init 会自动启用 git rerere，让冲突解决方案在多次 rebase 之间被记住，减少重复解决相同冲突的工作量。

AI 代理集成的意义

GitHub 同时发布了 gh-stack 的 AI agent skill。安装后，编码代理能够理解堆叠 PR 的概念并主动使用 gh stack 命令。这与 Hermes Agent、Claude Code 等工具的 subagent-driven development 工作流高度互补：当 AI 代理在一个任务中需要做多步变更时，可以把每一步变成堆叠的一层，而非塞进一个巨大的提交。

考虑到 stacked PR 的核心场景正是「AI 生成的批量代码需要被拆分评审」，这个 agent skill 的发布时机几乎是在回应 Andy Merryman 描述的那个痛点。

可用性

Stacked Pull Requests 在公开预览阶段对所有 GitHub 仓库免费开放。Merge queue 支持在未来几周内完整推出。详细文档见 GitHub Stacked PRs 文档，CLI 工具仓库在 github/gh-stack。