← #803

GitHub 原生支持堆叠式 PR 了

文章摘要

2026 年 7 月 30 日，GitHub 在 changelog 中宣布：堆叠式 Pull Request（stacked pull requests）进入公开预览。

所谓「堆叠」，就是把一个大改动拆成一串有序的、彼此依赖的小 PR，每个 PR 代表这次改动的一个聚焦层次。每个 PR 的目标分支指向它下面的那一层，从而形成一个栈。GitHub 给出的价值主张有三点：其一，让大改动持续推进——评审者可以并行地评审多个范围极窄的短 PR；其二，逐层保证质量——每一层都走聚焦的 PR review，配合现有的分支保护规则来守住 main；其三，合并粒度自由——可以一键落地整个栈，也可以一层一层单独合并。因为堆叠式 PR 是内建在 GitHub 里的，现有的 review、CI 检查、合并要求全都开箱即用。

合并语义是这次设计的核心。合并栈里最新的那个「ready」PR，会连同它下面所有未合并的层一起在一次操作中落地。如果只想落地栈的一部分，就合并底下的一层或几层，上面的 PR 保持打开状态，并自动 rebase 和重新指向新的目标分支。已有的分支保护和必需检查依然决定什么能进入 main。

工具链方面，GitHub 提供了 CLI 扩展，gh extension install github/gh-stack 就能装上，官方说一分钟内就能建出第一个栈。你可以在 github.com、GitHub CLI、GitHub 移动端上操作栈，也可以通过 gh-stack skill 让 GitHub Copilot 这类编码 agent 来操作。评审时打开栈中任意一个 PR，只会看到那一层的 diff，PR 顶部有一张「栈地图」显示你正在看的这块改动在整体工作中的位置。

changelog 里引用了三段客户证言，其中两段直白地把这个功能和 AI 编程联系在了一起。Vercel 的 Next.js 负责人 Tim Neutkens 说他们已经用了几个月，在交付大功能的同时能引入更小的单个改动。TED 的 CTO Andy Merryman 说得最直接：「AI 让 TED 的开发者生产力大幅提升，但这制造了一个新瓶颈——PR 大到评审者根本吃不消。堆叠式 PR 帮我们解决了这个问题。」jQuery 作者 John Resig 则称赞把 5 个堆叠 PR 一次性推进合并队列的体验「A+++」。

功能会在接下来几天内向所有仓库滚动发布，合并队列（merge queue）对堆叠 PR 的支持会在随后几周内逐步推出。

HN 评论精华

GitHub 官方派人下场是这条讨论的一大特色，而讨论本身大致分成「终于来了」「这不就是精心整理的 commit 吗」「预览版 bug 太多」三派。

官方现身与产品细节

sameenkarim（GitHub 堆叠 PR 团队）开了一个 42 条子回复的串：「很高兴能更广泛地发布它……也很乐意回答我们做的设计决策相关的问题。背后发生了很多事，这是 GitHub 历史上最大的发布之一，几乎覆盖了从 Actions、保护规则到 CLI 和移动端的每一个服务。」
面对 squash merge 相关的 bug 投诉，他给出了内部机制解释：GitHub 有一个叫 CPRMC（Create Pull Request Merge Commit）的系统用来判断 PR 是否「可以合并」，涵盖从可合并性（冲突检查）到规则评估（确保 approval 与合并将产生的那个 commit 相匹配）在内的一切。当要 squash 合并一整个栈时，必须先算出一串 squash 后的 commit，再把它们关联回规则和 review，因此格外困难——修复正在陆续发布。
关于 UI 太单薄的批评，他也承认：「我们不得不从更精简的东西开始，但我们正在做一次范围大得多的 PR 界面改版，其中会包括一个常驻的栈视图。」
leo60228 问跨 fork 的堆叠 PR 什么时候支持，认为这对公开仓库的可用性相当关键。camilomatajira 想要的是跨仓库堆叠：一个栈里同时包含后端、前端和 ArgoCD 的 PR，并规定顺序。

「这和好好整理 commit 有什么区别」

这是最大的一条讨论串（51 条子回复），由 Okkef 发起：「相比一组精心整理的 commit、逐 commit 评审，这种堆叠 PR 的好处是什么？我觉得更大的问题是大体量 AI PR 需要一种不同的评审方式——比如 diff 的展示顺序就能极大影响可读性（先看函数定义的变化、再看所有调用点、最后看测试）。也许我们该走向一种 diff 与评论交织的系统，有点像『文学式编程』把代码和散文交织起来。文学式 diff、文学式 PR……我还没找到类似的东西。」

dastbe 的回应最有说服力：对于用惯了 Phabricator 那套 stacked diff 的人来说，「这恰恰就是逐个评审一组精心整理的 commit」。区别在于：认知上，评审单元（一个 PR、一个 diff）始终是一个界限清晰的改动，评论聚焦于这个改动，而 PR 不会随着功能规模变大而膨胀；另外还能把栈的不同部分定向给不同受众——某一层可能需要外部团队评审，另一层不需要。
madeofpalk 一句话概括：「它基本上就是『一组精心整理的 commit + 逐 commit 评审』的一个 UI。」
kazinator 站在反面：「PR 本来就是堆叠起来的 commit。这不需要递归；你不需要堆叠 PR，更不需要堆叠 PR 的栈。」
OJFord 给了本串最辛辣的一句：「辛辣观点：这是给那些把 commit 当成『文件 > 保存』用的人重新发明的 commit。……不过如果最终结果是让『堆叠的逻辑改动』更流行，那还是好事。」
rrradical 列了他理解的两个真实用例（跨仓库的关联改动、以及在第一个 PR 评审期间继续往上堆以实现流水线作业），然后表示这个功能好像哪个都没命中。piskov 回复说第二个场景的正确姿势是从父分支再开新分支，像 git-tower 那样在父分支被评审意见修改后自动 restack 所有子分支。hypendev 则对第一个场景不抱希望：「这对一小撮高级用户会是极其有用的功能，所以他们永远不会做。」

和 AI 的关系

8260337551：「欢呼吧，终于有一个和 AI 无关的新功能了。」techscruggs 立刻纠正：「我懂你的意思，但它其实是跟 AI 有关的。AI 之后 PR 的体量让 diff 难评审太多了，堆叠 PR 看起来就是对这个问题的回应。」smoll 说得更实际：「虽然和 AI 无关，但我打算让我的 agent 大量使用它，这样我就能一小块一小块地评审，而不是一次性面对全部。」
hungryhobbit 注意到 GitHub 和 GitLab 最近都上线了堆叠 MR 技术，「我猜大家现在都在提交巨大的 AI 写的 PR，确实存在把它们切成人类可评审块的真实需求。」但他认为两家都「相当平庸」，并提出一个具体诉求：应该有个「路标」功能让作者在评审前给自己的代码打注解——现在只能用 review comment 代替，结果合并前要清掉一堆自己留的评论，而且它们和评审者的评论长得一模一样。

预览版的真实状况

matharmin 是最详尽的实测反馈：「我用了一阵预览版，很惊讶他们在这么多问题没修的情况下就扩大了预览。」合并整个栈在很多情况下完全是坏的；可以逐个合并，但如果你用 squash and merge 且要求 review，每个 PR 都需要重新 approve——这等于丢掉了堆叠 PR 最大的收益之一。命令行工具 gh stack 有帮助，但你仍然需要非常清楚 git rebase 的工作方式，工具只是把它跨多分支自动化了；比如 UI 建议你运行的 gh stack rebase 在本地分支与远端不同步时不会生效，而工具不会提示你。他对栈的 UI 评价正面：相当精简，但足以展示 PR 之间的关系。
lucideer 的失望更彻底：CLI 工具很棒，但拿到预览资格后发现网页端「几乎没有任何有意义的 UI 变化」——PR 依然显示为互相独立的，只是顶部多了一个列出栈中其他 PR 的小下拉框。
jeremy_k：唯一的抱怨是 gh stack rebase 在 squash merge 之后处理 rebase 有困难，不过官方回复说已经改进了。
Chyzwar 一句吐槽：「笑死，也许他们该先修好大 PR 会让 UI 崩溃/卡死的问题。」
lucky_cloud 提了个有趣的小细节：菜单开关用的是煎饼堆 emoji（U+1F95E），「俏皮没问题，但这个改动让我对自己在看什么东西起了很大疑心。」

其他生态与反对意见

tao_oat（最高赞开场）：用过 Graphite 之后再回到没有栈的 GitHub 非常痛苦，希望这能让堆叠 PR 工作流更普及。theappsecguy 推荐开源的 git-spice，认为 Graphite 把简单的事做复杂了。
sepeth 和 yes_but_no 力推 jujutsu：更新一个分支时会自动 rebase 从它派生出去的分支，jj absorb 能把改动自动挪到最相关的那个 change 上。Scoring6931 补充纯 git 方案：git rebase --update-refs。
steveklabnik：「这是许多年来 GitHub 最大的改动之一。很高兴看到它被部署到世界上最大的代码托管平台之一，希望它能让很多开发者接触到他们此前根本不知道的工作流。」
_doctor_love 唱反调：「我大概属于某种少数派。我仍然认为堆叠 PR 是魔鬼，是组织和流程问题上的一块创可贴。」msalsas 更直白：「没看出意义，把你的 PR 写小就行了。」pyth0 回敬：「那正是这个功能的意义。」
ymir_e 从竞争格局切入：最近很多人抱怨 GitHub 的宕机、性能和整体质量，「很高兴看到往正确方向走的东西，我觉得他们稍微醒了一点。大公司动作能有多慢仍然令人吃惊。Linear、Vercel、Zed、Cursor 这些公司都在更激进地盯着 GitHub，我怀疑很快会有更多竞争。」