GitHub 终于把那种没法 Review 的超级 PR 给干掉了

一个 PR 如果改了 40 多个文件，Diff 长度直接刷屏，审代码的人看到“加载更多”出现十七次基本上就想直接点 Approve 赶紧打发了。这种巨型 PR 简直是代码质量的坟墓，哪怕是用 AI 辅助 Review，面对两千行代码的墙，模型也容易产生幻觉或者漏掉关键 Bug。

GitHub 这次悄悄更新的 Stacked PR（堆叠 PR）其实就是为了解决这个问题。简单说，就是把一个巨大的改动拆成一串相互依赖的小 PR。每个 PR 只包含它真正引入的 Diff，而不是把下面所有分支的改动全部堆在一起。

这个逻辑其实很简单，只要满足两个条件：

• 最底层的 PR 目标分支是 main（主干）。
• 之后的每一个 PR，目标分支都是它的前一个 PR 分支，而不是 main。

这样一来，底层放基础架构、Schema 或公共类型，上层放具体的 API 路由或 UI 逻辑。最让我意外的是，这玩意儿不需要什么特殊工具，只要你用原生 git 分支手动操作，GitHub 的 UI 就能自动识别出这是一个 Stack 并弹出提示。

我自己在项目里实操了一把，本来想用 gh stack 命令，结果发现 Ubuntu 的 apt 仓库版本太低，直接报错：

$ gh stack --help
unknown command "stack" for "gh"

于是我回到了最原始的 git 分支操作法，直接在终端里把分支链条给接上了。具体流程是这样的：

一、创建并推送链式分支

# 创建三个递进的分支
git checkout -b stack/01-setup-database
# ...做一些基础修改...
git commit -am "setup db"

git checkout -b stack/02-api-endpoints
# ...在这个基础上写 API...
git commit -am "add api"

git checkout -b stack/03-setup-frontend
# ...最后写前端...
git commit -am "add ui"

# 一次性推送到远程
git push -u origin stack/01-setup-database stack/02-api-endpoints stack/03-setup-frontend

二、通过 gh CLI 创建关联 PR
这里的关键是 --base 参数必须指向前一个分支。

# 第一个 PR 指向 master
gh pr create --base master --head stack/01-setup-database --title "demo: setup database layer"

# 第二个 PR 指向第一个 PR 的分支
gh pr create --base stack/01-setup-database --head stack/02-api-endpoints --title "demo: add api endpoints"

# 第三个 PR 指向第二个 PR 的分支
gh pr create --base stack/02-api-endpoints --head stack/03-setup-frontend --title "demo: setup frontend"

这样操作后，在 GitHub 页面上，每个 PR 显示的 Diff 只有当前步骤的增量，审代码的人压力小了，效率自然就高了。