GitHub Stacked PRs 公测了——这个功能让我决定把代码审查流程全换了

说实话，我看到「Stacked PRs」这个功能的时候，第一反应是：GitHub 终于把这件事做出来了。

代码审查这件事，前端团队做久了都知道，最烦的不是写代码，是等 PR 审查。那些大功能憋了两周，一个 PR 改了 80 个文件，reviewer 点开一看心态直接崩。要么就是一层套一层，改完这个那个又 conflict 了，rebase 能 rebase 一下午。

GitHub 上周把这个功能推进到了公开预览，我第一时间装上跑了几天。说结论：这东西是真的有用，不是 demo 级别的展示品。

它解决了一个什么问题

传统的代码审查逻辑是：一个功能 = 一个 PR。大功能只能拆分支，分支之间手动 rebase 维护顺序，reviewer 面对一个巨大的 diff 很难下手。

Stacked PRs 换了个思路：一个功能 = 一叠 PR。每一层 PR 代表改动的其中一个 Layer，底层 PR 先 review 和 merge，上层的 PR 自动跟随。最后一键把整叠都 merge 进去。

举个例子，你做一个登录重构，可以拆成：

• PR #1：改掉旧的 auth 工具函数（基础层，先 review 先 merge）
• PR #2：把组件层接新函数（依赖 #1）
• PR #3：更新页面路由权限（依赖 #2）

reviewer 可以只看 #1 的 diff，确认后 merge。然后 #2 自动更新 target，再 review #2。每一层的上下文都是干净的。

前端团队的真实价值

Next.js 团队的 Tim Neutkens 在官方博客里说了一句很实在的话：用 Stacked PRs 之后，大功能可以拆成更小的 PR 来 review，整个过程变得更顺畅了。

John Resig（jQuery 作者）更直接：一次性把 5 个 stacked PR 直接 landing 到 merge queue，体验是 A+++。

这对前端团队意味着几件事：

review 质量会变好。 小 diff 更容易发现细节问题，reviewer 不容易漏掉东西。

并行 review 不再需要协调。 团队成员可以同时 review 不同的 layer，不用等某个人先看完 #1 才能看 #2。

merge 顺序有保障。 底层没通过，上层的 CI 不会跑偏。每个 PR 的 target 自动指向它的下一层，依赖关系一目了然。

怎么开始

安装 CLI 扩展：

gh extension install github/gh-stack

创建一个 stack：

# 先创建第一个 PR
gh pr create --base main

# 在这个 PR 基础上继续加 layer
git checkout -b feature/auth-base
# 写代码...
gh pr create --base feature/auth-base

git checkout -b feature/auth-components
# 写代码...
gh pr create --base feature/auth-components

现在打开任何一个 PR，顶部会有一个 stack map，显示当前 PR 在整叠里的位置和依赖关系。review 的时候可以直接看对应 layer 的 diff，不用在脑子里维护整个功能的上下文。

和现有的流程冲突吗

不冲突。Stacked PRs 是 GitHub 原生功能，现有的 branch protection、required checks、CODEOWNERS 全部继续生效。reviewer 的权限管理和通知逻辑也没变。

唯一需要调整的是团队习惯：把「一个大功能一个 PR」换成「一个功能拆成多个小 PR」。初始成本确实有一点，但跑顺了之后 code review 的体验会上一个台阶。

适合谁用

如果你团队的特点是：

• 功能分支生命周期长，经常一个 PR 卡着好几天 review 不动
• 多人协作，同一个功能的改动分布在不同文件，互相 blocking
• CI/CD 配置复杂，merge 前需要通过多个 gate

Stacked PRs 值得你认真试试。现在是公开预览，装上跑两个真实 PR 感受一下，比看文档更直接。

说实话，我跑了几天之后，最直接的感受不是「效率提升了多少」，而是等 review 这件事变得没那么焦虑了——因为每一层的 scope 都足够小，reviewer 给出反馈的速度会快很多，而这往往才是大功能推进真正的瓶颈。