GitHub堆叠拉取请求正式可用

GitHub在2026年10月6日宣布堆叠拉取请求正式可用：把存在依赖的大改动拆成更小的PR，分别评审，再按依赖关系合并。功能面向github.com所有方案；GitHub Enterprise Server将由后续版本提供，不能把云端正式可用理解为服务器版本已经同步上线。GitHub发布公告

官方地址：https://github.com/

什么样的变更适合堆叠评审？

假设一个功能分为“基础类型”“服务逻辑”“接口适配”，后两部分依赖前面的改动。这个虚构例子里，拆分的目的不是让三项工作完全独立，而是让每次评审只围绕一个清楚的责任范围。反过来，三个互不相关的修复，没有必要仅为了凑成一组而建立依赖。

最小采用方式可以先从一组两层依赖变更开始：在PR说明中写清本层新增内容，以及依赖的下层工作。这里只给出团队协作建议，不声称它是GitHub强制要求的模板。

正式可用不等于获得合并权限

公告提到，已有绕过仓库规则权限的用户，可以在堆叠中对最底部未合并PR使用该权限；这不是向所有使用者新增绕过权。公告还说明，代码差异不变时，基线前进后的堆叠变基能够保留批准记录，并生成带签名的替代提交。权限与变基改进

团队采用时，先明确谁负责评审、谁允许合并、谁维护分支规则。不要因为工具能够集中处理依赖，就把所有责任都交给同一个自动化账号，更不要把绕过能力当成正常合并路径。

CI会只检查最底部PR吗？

不会。官方CI文档说明，堆叠中的每个PR都按最终基线分支来评估；面向main的pull_request工作流可以在各层触发。因此拆分评审并不自然等于减少CI运行次数。堆叠越大，同类检查的重复运行越值得关注。堆叠CI文档

工作流可读取stack元数据，但只有属于堆叠的PR才有该属性，读取字段前需要考虑普通PR。文档区分最顶层与当前最底部未合并层：前者包含完整变更，后者会随着底层合并而变化，不能始终拿原始位置1代替当前底层。是否把昂贵任务限制在某层，应根据测试覆盖需求决定，而不是只为了减少运行次数。

合并时看的是整组条件

合并从靠近主干的底部向上进行，可以一次合并从最低未合并PR开始的连续组；不能孤立合并中间层而把下层留在原地。合并框反映整组状态，下层批准与检查、线性历史，以及当前PR对最终基线的分支保护要求，都影响是否能够落地。堆叠合并文档

一个易读的内部速查表可以这样使用：

失败后如何避免连带误判？

官方文档说明，在合并队列中，一层被移除或退出队列时，上方依赖层也会被移除。此时不能把上层离开队列一概解释成上层代码自身失败，应先定位是哪一层及什么条件导致退出。部分合并后，下一个未合并PR会自动变基到堆叠基线，成为新的底层。队列与部分合并行为

建议通知中同时记录受影响的PR、当前依赖层和阻塞原因。这样评审者能判断是修改自己的变更、等待下层更新，还是联系仓库维护者；不要只发送一条没有上下文的“堆叠失败”。

自动合并还需要留意推出阶段

正式可用公告把堆叠自动合并列为接下来几周逐步推出的能力：满足仓库合并要求后，选定的一组PR可以一起合并。不能据此宣称每个仓库现在都有入口；合并文档也仍提示不支持自动合并。两处资料的表述存在推出阶段差异，因此应把该能力单独核对，不要将它作为采用堆叠的既定前提。自动合并推出说明

这次更新适合解决依赖变更难以分层评审的问题。采用时最值得先对齐的，是每层责任、CI覆盖和合并条件；正式可用扩大了使用范围，并没有取消这些工程约束。