GitHub 堆叠式 Pull Request 正式发布
2026-10-07
GitHub 的堆叠式 pull request 现已正式可用。把大型改动拆成更小、更聚焦的 pull request，你可以独立评审它们并一起合并。自从该功能进入公开预览以来，使用堆叠的仓库相比同类仓库，已合并代码量增加了 9%。排名前 1% 的仓库中，超过三分之二现在使用堆叠式 pull request，并且合并所需时间改善了 5%。随着这次正式发布，我们引入了几项改进，让堆叠更易于创建、评审和合并。感谢所有在预览期间提供反馈和意见的人。
未变更代码的批准保持有效。当一个原本未变更的堆叠在其基础分支（例如 main）前进之后被更新时，Rebase stack 现在会保留批准，即使在会作废过期批准的仓库中也是如此。变基后的提交保持签名。GitHub 在 Rebase stack 期间创建签名的替换提交，保留原始作者身份。部分合并后的自动变基，在分支规则要求签名或任何原始提交已签名时，也会对替换提交签名。
绕过权限适用于堆叠。拥有绕过仓库规则权限的用户，现在可以使用这些权限来合并堆叠中最低的未合并 pull request。更一致的堆叠合并。一个堆叠现在作为单个合并组进入并通过合并队列落地。在使用 merge commit 方式时，GitHub 现在为每个 pull request 创建一个合并提交，而不是为整个合并组创建一个。分支堆叠自动重新指定目标。当一个堆叠的基础分支被删除时，GitHub 会自动重新定向该堆叠，而不是关闭其最底部的 pull request。这支持一个堆叠从另一个堆叠分出的工作流。
堆叠的自动合并将在未来几周内逐步推出。堆叠式 pull request 可以设置为在仓库的合并要求满足后自动合并。选择一组 pull request，当所有 pull request 都准备好合并时，它们将一起合并。“用 GitHub 的 Stacked PRs 合并一次，我就断定它很棒。”——Charlie Marsh，Astral 创始人。
堆叠上下文保持可见。堆叠信息现在始终显示在 pull request 页面的常驻头部。可以从 pull request 列表视图查看某个 pull request 所属堆叠的详细信息。
GitHub 宣布堆叠式 pull request 正式可用：把大改动拆成多个小 PR，可独立评审、一起合并。预览期内使用堆叠的仓库合并代码量比同类仓库多 9%，前 1% 仓库中超过三分之二在用，合并耗时改善 5%。本次正式版还带来批准与签名保留、绕过权限、合并队列按单组落地、分支堆叠自动重新指向等改进，自动合并将在未来几周逐步推出。
- GitHub 宣布堆叠式 pull request 正式可用：把大改动拆成多个小 PR，可独立评审、一起合并。预览期内使用堆叠的仓库合并代码量比同类仓库多 9%，前 1% 仓库中超过三分之二在用，合并耗时改善 5%。本次正式版还带来批准与签名保留、绕过权限、合并队列按单组落地、分支堆叠自动重新指向等改进，自动合并将在未来几周逐步推出。
- 原贴提到：GitHub stacked pull requests are now generally available. Break large ch
- 来源：github.blog
这是什么信号
GitHub 把堆叠式 pull request 从公开预览推到了正式可用。这不是一个新概念——堆叠 PR 在 Meta、Google 等大型工程组织里已经用了很多年，但在 GitHub 原生支持之前，中小团队要自己搭工具链才能用。现在它变成了平台能力，意味着这套工作方式从“少数团队的自建流程”变成“默认可选项”。
更值得注意的是这次正式版的内容：保留批准、保留签名、绕过权限、合并队列按单个堆叠落地、基础分支被删后自动重定向。这些都不是炫技功能，而是把堆叠从“能玩”推到“能在有分支保护和合规要求的仓库里用”。
为什么重要
GitHub 给了两个参照数据：公开预览以来，使用堆叠的仓库相比同类仓库已合并代码量增加 9%；排名前 1% 的仓库中超过三分之二在用堆叠，合并所需时间改善 5%。前者说明堆叠让更多代码真正被合并，而不是卡在评审队列里；后者说明它压缩了从提交到合入的周期。
这两个指标指向同一个结构性矛盾：大 PR 难评审、小 PR 又难以组合上线。堆叠把“变小”和“一起合”这两件事同时解决了。对工程组织来说，这不只是效率数字，而是代码评审文化能不能真正落地的前置条件。
对谁有价值
- 正在被巨型 PR 拖慢评审节奏的研发团队：拆小之后单个 PR 可以独立评审，减少“一次看两千行”的评审疲劳。
- 有严格分支保护与合规要求的企业仓库：批准在未变更代码上不被作废、变基后提交保持签名，这些是能否通过内部审计的关键。
- 平台与研发效能团队：合并队列按单个堆叠作为一组进入和落地，减少了等待与冲突重排的运维复杂度。
- 高频提交的个体开发者：把工作流从“攒一个大 PR”改成“一串小 PR 并行推进”，能显著降低上下文切换成本。
可以怎么行动
第一步不是全员推广，而是选一个中等规模的改动做试点，观察拆分粒度、CI 触发次数和评审往返次数是否真的下降。第二步是配套规则：既然批准和签名会保留，就需要明确团队对“堆叠中哪一层必须由谁批准”的约定，否则自动保留会变成默认放行。第三步是等自动合并全量开放后再把“整组一起合”接入日常流程，现阶段不建议把它写进强制规范。
风险或限制
几个需要留意的点：自动合并目前是“未来几周逐步推出”，不是立刻全量可用，依赖它做流程设计会有时间差风险。堆叠对团队协作习惯有要求，如果评审者不按层看、随手改底层，整条堆叠都要重跑。合并队列与签名规则叠加后，CI 成本和等待时间可能上升，仓库规模大时尤其明显。另外，堆叠会让“谁该负责最终合入”这件事变得模糊，需要团队自己补上约定的空白。
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《GitHub 堆叠式 Pull Request 正式发布》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。