GitHub 官方下场做 Stacked PR：长分支地狱有救了，但别急着全团队推广
GitHub 官方下场做 Stacked PR：长分支地狱有救了，但别急着全团队推广
你的 PR 又憋了三天没合。功能早写完了，卡的是分支。从 main 拉出来那一刻起，它就在跟别人的分支打架。main 动一下，你 rebase 一次；冲突刚解完，main 又动了。等 reviewer 终于点开 PR，看到三百个文件的 diff，扭头就走。
这不是你的问题。这是"一个功能一个分支"这个模式的天花板。
GitHub 前两天发了个官方工具 gh-stack，把堆叠式 PR 从第三方插件和自建脚本里捞了出来，变成官方支持的工作流。大厂下场通常说明两件事：这东西是刚需，而且它快要变成默认配置了。
先搞清楚：堆叠 PR 到底是什么
普通 PR 是一棵树，每个分支都从 main 长出来，互不相干。堆叠 PR 是一条链：
frontend → PR #3（base: api-endpoints）← 最顶层
api-endpoints → PR #2（base: auth-layer）
auth-layer → PR #1（base: main） ← 最底层
─────────────
main
每个分支只基于下面那个分支，不基于 main。提交的时候，GitHub 给每个分支建一个 PR，每个 PR 的 base 就是它下面那层。
好处在这：reviewer 打开任何一个 PR，看到的只有那一层的改动。不是三百个文件，是三个文件、一个明确的主题。
换个说法。普通 PR 是把整个项目打包成一个巨大 diff，塞给一个人审。堆叠 PR 是把大改动切成一层层小步，每步单独审、单独合。
为什么官方下场是件大事
堆叠 PR 不是新概念。Graphite 那批第三方工具做了好几年，不少大厂内部也有自建脚本。但它一直是少数人的高级玩法：
- 第三方工具要订阅，数据存在别人家
- 自建脚本要人维护，rebase 断在半路没人管
- 团队里每个人对分支的理解都不一样，策略各玩各的
gh-stack 把这些全踩掉了。一个 gh CLI 扩展，一行装完：
gh extension install github/gh-stack
栈的元数据存在本地 .git/gh-stack 目录，一个不入库的 JSON，不依赖任何第三方服务。它只跟你的 GitHub 仓库绑定，不产生新的数据孤岛。
还有个细节：gh stack init 会自动打开 git rerere。rebase 时它记下你解过的冲突，下次撞上同样的冲突自动帮你解。会想到这一层，说明它是冲着真实的大型 codebase 去的，不是玩具。
实际怎么用：十分钟上手
基础流程就四条命令：
# 开始一个 stack，创建并检出第一个分支
gh stack init
# 在当前 stack 顶部加一层新分支
gh stack add api-endpoints
# 把全部分支推到远端
gh stack push
# 为每一层创建 PR，自动设置好 base 链条
gh stack submit
gh stack add 还能一条龙：暂存改动、提交、自动起分支名。
# 暂存全部改动、提交、自动生成分支名（如 03-24-add_login）
gh stack add -Am "Add login endpoint"
日常切换也方便，gh stack checkout 吃分支名、PR 号，甚至 PR URL 都行。想看整个栈长什么样，gh stack view。
上手成本比想象低。你不用重学 git，它只是在上面加了一层编排。原来手动维护依赖分支链的人，换过来是降维打击。
泼盆冷水：什么时候别用
堆叠 PR 不是银弹。我劝你先别急着全团队推广。
小型改动不需要。 一个 PR 就几十行、两三个文件，堆叠是纯开销。链式依赖带来的全是额外心智负担：改动在第几层？合了中间层会不会影响上层？这层 rebase 崩了会不会连锁？
单人项目不需要。 你自己就是唯一的 reviewer，没人需要"只看一层 diff"。堆叠 PR 解决的是协作问题，不是个人效率问题。
rebase 冲突多的团队要谨慎。 链越长，rebase 的连锁反应越强。中间任何一层冲突，都可能牵连上下几层。rerere 能兜一部分，但冲突本身还是得人来解。分支老是互相踩的团队，先去搞清楚"为什么会冲突"，别拿更复杂的链式结构把这个问题盖住。
工具还年轻。 GitHub 自己标了早期阶段。生产环境大规模铺开之前，先看几个版本迭代、听听社区反馈——官方工具都是这个节奏。
我的建议
在大型 codebase 里做长功能，或者团队的 PR 动不动上百个文件，今天就花十分钟试试：gh stack init 起个两层的小栈，跑一遍 add 和 submit，感受下 reviewer 视角的 diff 有多清爽。
全是小改动、单人维护、连分支规范都没定，那先别上。把基础的分支策略理清楚，比引入新工具重要得多。
堆叠 PR 就解决一个问题：大改动怎么被好好 review。官方下场，意味着它从高级玩法变成了标准工作流。但标准工作流不等于哪儿都能用——工具是给配得上它的人用的。
参考来源
- GitHub 官方 gh-stack 仓库：https://github.com/github/gh-stack
- 码农早餐 · 2026-08-02：GitHub 推出官方 Stacked PR 工具
✨ 本文由 DeepSeek 生成初稿，Claude 审核润色。