一句话看懂：GitHub 的堆叠式 Pull Requests 结束公开预览转为正式可用，并新增 rebase 保留审批、签名提交、合并队列按单个 PR 出提交等改进，目标是让大型代码变更拆成小 PR 独立评审后一起合并。
事件核心：发生了什么
GitHub 于 2026 年 10 月 6 日宣布堆叠式 Pull Requests 正式可用。该功能把一个大改动拆成多个相互依赖、可独立评审的小 PR，最后统一合并。
GitHub 给出的预览期数据包括：使用堆叠的仓库合并代码量比同类仓库高出 9%；排名前 1% 的仓库中超过三分之二已在使用该功能，其合并耗时改善 5%。
正式版带来的变化集中在合并与导航两侧。Rebase stack 现在会在基线分支前进后保留原有审批，即使仓库开启了“新提交即作废审批”规则；rebase 产生的替换提交保持签名，部分合并后的自动 rebase 也会在分支规则要求或原提交已签名时签名。合并队列把整个堆叠当作一个合并组处理，使用 merge commit 方式时按单个 PR 生成合并提交，而非整组一个。基础分支被删除时，堆叠会自动重定向而不是关闭底部 PR。此外还加入了堆叠上下文常驻显示、Shift+J / Shift+K 快捷键导航、成员变更时间线与 webhook 的 stacked 动作，gh stack 扩展开始支持 Git worktree。自动合并（auto-merge）将在未来几周逐步开放。
为什么重要
这并非 AI 模型或算力层面的更新，而是代码协作基础设施的调整。随着 AI 编码助手把单次改动规模推高，评审环节反而成为瓶颈：一个几千行的 PR 几乎无法被认真 review。堆叠式 PR 把“写代码”和“合代码”解耦，让评审颗粒度回到人和工具都能处理的大小。GitHub 用合并量提升和合并耗时下降作为指标，说明这种拆分方式在头部仓库已经形成惯性。对以 GitHub 为中心的开源生态和依赖 PR 流程的企业团队而言，这属于工作流层面的默认选项变化，可能影响 CI 配置、分支保护和自动化脚本的写法。
对用户/开发者/创作者的影响
对日常提交 PR 的开发者，最直接的变化是 rebase 后审批不再轻易失效，减少了反复找 reviewer 重新点approve的沟通成本；签名提交被保留，也降低了受签名分支规则约束的团队的操作摩擦。使用合并队列的团队需要留意语义变化：整组进入队列，但 merge commit 方式下按 PR 逐个生成提交，历史结构与以往不同。维护 gh stack 或自建自动化流程的人，可以接入新的 stacked webhook 动作与 worktree 支持。对使用 AI 编程代理批量生成改动的团队，堆叠式 PR 提供了一种把机器产出切成可审单元的现成容器。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 auto-merge 在未来几周上线后的实际表现，尤其是它与合并队列、分支保护的交互是否稳定。二是 GitHub Enterprise Server 的纳入时间表，这决定自托管企业何时能用上。三是 GitLab、Bitbucket 等竞品是否跟进同类堆叠评审能力，以及围绕 gh stack 的第三方工具生态会不会扩大。
