GitHub 原生支持堆叠式 PR，想解决大 PR 难审难合并的问题。
原文标题：写代码的人都懂：GitHub 开始解决“大 PR 地狱”
原文作者：AI前线
冷月清谈：
怜星夜思：
2、GitHub 把堆叠式 PR 做成原生功能后，Graphite 这类第三方工具还有优势吗？
3、堆叠式 PR 会不会让开发流程更复杂，尤其是对新人不太友好？
4、文章里提到 AI 代理也能学会创建和管理堆叠式 PR，这会不会改变代码评审方式？
原文内容
GitHub 已通过一个名为 gh-stack 的新 CLI 扩展推出原生的堆叠式拉取请求工作流，填补了多年来一直由第三方工具弥补的空白。该方案的目的是解决大型拉取请求难以审查、合并缓慢且容易产生冲突的问题；GitHub 表示，在这种情况下，审查者会丢失上下文，反馈质量下降，整个团队的效率也会随之降低。
堆叠式拉取请求（有时也称为依赖式或链式 PR）是一种代码评审模式，在这种模式中，每个分支并不是直接指向主分支，而是按顺序指向其下方的前一个分支。该方法使开发者能够在较早层仍在审查时，继续推进功能后续层的开发工作。
我曾花费大量时间等待代码评审完成，这也是我构建这个工具的主要动机。Phabricator Differential 的共同创建者 Evan Priestley 表示。
发布公告中引用的研究表明，这种工作流具有可量化的收益。一项对 150 万个拉取请求的分析发现，200 到 400 行之间的 PR 缺陷减少了 40%，审批速度比更大的 PR 快了三倍。堆叠式方法的设计目标，是即便底层功能规模较大，也能让每个单独的 PR 保持在这一范围内。
gh-stack 扩展与现有的 GitHub CLI 集成，并处理了历史上让堆叠式工作流难以手动维护的各种机制。其核心命令 gh stack sync 会在整个堆栈中级联执行 rebase，并在对较早层进行更改后，以原子方式强制推送每个分支。GitHub 的拉取请求界面新增了堆栈映射，使审查者可以在各层之间导航；分支保护规则则针对最终目标分支生效，而不是每个 PR 的直接基线分支。CI 也会像每个 PR 直接指向主分支一样运行。
该扩展还集成了 AI 代理。运行 gh skill install github/gh-stack 可以让兼容的 AI 编码代理学会如何创建和管理堆栈，从而能够将大型 diff 拆分为多个层，或在任务一开始就采用堆栈方式进行开发。
CLI 是完全可选的，你也可以仅通过 UI 创建堆叠式 PR。 GitHub 的 Sameen Karim 表示。
堆叠式 diff 模式在软件开发中并非新事物。Meta 和 Google 早在近十年前就采用了类似的工作流，并构建了包括 Phabricator 和 Gerrit 在内的自定义工具。Simohamed Marhraoui 早在 2021 年就在 LogRocket 上撰文指出，该方法已适用于 GitHub，但需要注意合并策略：squash 和 rebase 合并都会重写提交哈希，从而破坏用于在堆栈中关联分支的身份追踪。Marhraoui 提到的限制——在链式 PR 的中间层只能使用标准的 merge commit——在 GitHub 上的任何堆叠式工作流中仍然是一个现实问题。
在发布后不久，Alan West 在 dev.to 上撰文指出，git 本身并未提供任何机制来管理依赖分支之间的关系。“当你对第一个分支执行 rebase 时，所有下游分支也都需要手动 rebase，”West 写道，并描述了一个五步的流程，开发者在每次审查者要求修改早期 PR 时都必须重复执行。West 认为，一个堆栈中包含三到四个 PR 是较为实际的上限：“超过这个数量，跟踪依赖关系所带来的认知负担将开始超过评审带来的收益。”
GitHub 的主要竞争对手 Graphite 由前 Meta 工程师创立，目前已无需等待列表即可使用。Graphite 提供支持堆栈的合并队列、基于 Web 的评审界面、VS Code 集成以及 CLI。其免费版本包含 CLI 和堆叠工作流；付费方案起价为每位用户每月 20 美元。Joe Buza 在 2026 年 2 月于 LinkedIn 上表示，他一直在引导 AI 编码代理使用类似 Graphite 的工作流，将功能拆分为堆叠式 PR，将每个 PR 限制在 200 行以内，并要求每一层“只完成一个逻辑目标，并且自身具备完整意义”。
社区对 GitHub 此次发布的反应不一。Hacker News 上关于该发布的讨论帖获得了 516 分和 282 条评论。其中一种观点认为，这是对长期以来只在大型工程组织中使用的模式的一种主流认可：“堆叠式 diff 在 Meta 已经存在十年，很高兴看到 GitHub 终于来到 2016 年。”另一种持怀疑态度的观点则质疑这种工作流是否适合 GitHub 的基础设施：“要么变更是独立的，那就使用独立的 PR；要么它们是依赖的，那单独审查就没有意义。”还有一种批评意见（由 ByteIota 总结）指出，squash 合并的兼容性以及级联 rebase 冲突仍是尚未解决的技术问题，而 Graphite 已经有数年时间来处理这些问题。
GitHub 进入堆叠式 PR 领域的一个显著特点在于：其堆栈映射和规则执行逻辑直接内置于拉取请求 UI 中，这意味着审查者无需额外账户或扩展即可查看上下文。官方文档指出，CLI 是“完全可选”的，堆栈也可以直接通过 GitHub 的 UI 或 API 创建。这样的原生集成是否足以吸引已经使用 Graphite 的团队，或将该工作流推广给从未尝试过堆叠方式的开发者，很大程度上取决于 GitHub 在私有预览期间如何处理各种边界情况。
该功能于 2026 年 4 月 13 日进入私有预览阶段，开发者需要加入等待列表后，扩展才能在其仓库中生效。InfoQ 的相关报道还包括：2026 年 2 月关于 GitHub 重构基础设施策略执行的分层防御机制的文章，以及 2026 年 4 月关于 Anthropic 为 Claude Code 引入基于代理的代码评审的报道，该报道发现，在采用自动化评审工具后，针对变更超过 1000 行的 PR，其具有实质性评审评论的比例从 16% 提升至 84%。
原文链接：
https://www.infoq.com/news/2026/04/github-stacked-prs/
