📰 概要

大型PR是代码审查的噩梦——审查者丢失上下文，反馈质量下降，合并速度缓慢。

2026年4月30日，GitHub通过gh-stack CLI扩展推出原生堆叠式PR工作流，填补了这个多年来一直由第三方工具弥补的空白。

核心数据：200-400行的PR缺陷减少40%，审批速度比更大PR快三倍。

---

🔍 解读

堆叠式PR不是新概念——Meta和Google早在近十年前就采用了类似工作流。

传统模式：每个分支直接指向主分支。大型功能意味着一个包含数千行改动的巨大PR。

堆叠模式：每个分支按顺序指向前一个分支，形成依赖链。大型功能被拆成多个小PR，每层都可以独立审查和合并。

gh-stack处理了堆叠式工作流最难维护的部分：rebase级联强制推送、堆栈映射导航。审查者可以在各层之间跳转，而不是面对一个巨大的diff。

更有意思的是：AI代理已集成。

---

💎 深挖

为什么大PR是个问题

研究分析了150万个PR，发现200-400行之间的PR缺陷率最低。超过这个规模后，审查质量显著下降。

堆叠式方法的设计目标，就是让每个单独的PR保持在这个最佳规模内，即便底层功能规模很大。

gh-stack的核心能力

gh stack sync命令：会在整个堆栈中级联执行rebase，并在对较早层进行更改后，以原子方式强制推送每个分支。

堆栈映射：GitHub的PR界面新增了堆栈导航功能，审查者可以在各层之间跳转。

分支保护规则：针对最终目标分支生效，而不是每个PR的直接基线分支。避免保护规则在中间层被阻断。

CI行为：和每个PR直接指向主分支一样运行。不需要额外的CI配置。

AI代理集成

运行gh skill install github/gh-stack，可以让兼容的AI编码代理学会如何创建和管理堆叠。

AI代理的典型任务：把大型diff拆分为多个层，或在任务一开始就采用堆叠方式开发。这是AI编程工具链的自然延伸——从生成代码到管理代码工作流。

仍存在的限制

Alan West在dev.to指出：git本身并未提供管理依赖分支关系的机制。对第一个分支做rebase时，所有下游分支都需要手动rebase。

合并策略也有约束：squash和rebase合并都会重写提交哈希，破坏堆栈中的身份追踪。链式PR中间层只能用标准的merge commit。

什么情况不建议用

如果你的团队PR规模本身就不大（大多数PR在200行以内），堆叠式工作流带来的复杂度可能超过收益。

如果项目需要频繁的squash merge（保持git历史干净），堆叠式PR会与这种工作流产生冲突。

如果团队成员不熟悉rebase操作，强制推送和级联rebase可能造成混乱。先确保团队有基础的git操作能力。