GitHub Stacked Pull Requests 公测怎么用：用 gh stack 把大改动拆成可独立审核的依赖链

不少功能改动同时动数据结构、接口逻辑还有前端实现，最后很容易堆成一篇没人愿意从头到尾啃完的超大 Pull Request。GitHub 在 2026 年 7 月 30 日把 Stacked Pull Requests 推入公开预览，支持把有依赖关系的改动拆成一串小 PR：底层 PR 先合并，上层 PR 直接建立在它的提交之上，审查和 CI 校验都可以分层推进。

这套能力适合「下一步工作依赖上一步落地，但不想干等上一步完全合入主分支」的团队。它不能把任意几个独立 PR 强行绑在一起，也不支持跨 fork 协作，采用前先理清改动的依赖关系和自家仓库的现有规则。

为什么大改动拆成 stack 后更容易审

假设一次登录改造需要先落地共享类型定义，再新增接口逻辑，最后接入页面交互。把三部分塞进同一个 PR，审查者看到的是一堆互相干扰的 diff；把它拆成 auth-types、auth-api、auth-ui 三层后，每一层只对应一个独立的逻辑判断。

核心优势不是 PR 数量变多，而是理清了依赖方向。上层分支可以直接调用下层已经实现的代码，但下层不能反过来引用还没开发的上层逻辑。这样每个 PR 的 diff 都更短，审查者也能在整体合并前提前指出某一层的潜在问题。

用 gh stack 建立第一条依赖链

GitHub 官方提供的入口是 GitHub CLI 扩展。先在已经装好并登录 GitHub CLI 的开发机上执行：

gh extension install github/gh-stack
gh stack init auth-layer

第一条命令安装对应扩展，第二条命令以当前主分支为基础创建并切换到底层分支。做完改动后照常暂存、提交并推送，再从这一层的提交点继续创建下一个依赖分支。

git add internal/auth/types.go
git commit -m "add auth request types"
git push -u origin auth-layer

接下来创建 auth-api，写完接口逻辑后打开第二个 PR；再基于这个分支创建 auth-ui。在 GitHub 页面上，每个 PR 都会展示 stack 依赖关系图，当前层只会展示相对于下方分支的改动内容。

检查、反馈和合并顺序怎么判断

Stack 并不会绕开现有的质量校验门槛。GitHub 官方文档说明，stack 里的每个 PR 都会按照底部主干分支的规则评估，所以中间层同样要遵守分支保护、CODEOWNERS 权限校验和所有必需检查规则。CI 也会在每个层级自动触发，团队需要留意重复构建带来的时间和资源消耗。

如果审查者要求修改底层的类型定义，直接在 auth-types 分支上完成修改并重新推送，再让上层分支自动级联重排提交。不要手动在三个分支各自复制同一处修改，不然很快就会出现底层已经修正、上层还保留旧补丁的冲突。

合并时严格遵循从下到上的顺序。合并最顶层的 PR 可以一次落地整个 stack；如果只合并中间层，下面的所有层会同步落地，上方还没合并的层会继续保持开放，并自动指向新的基础分支。合并队列支持逐步灰度发布，仓库实际可用状态以页面显示为准。

哪些项目暂时不适合采用

• 几个 PR 之间没有真实依赖，只是同一迭代的并列任务：直接用普通独立 PR 追踪更简单。
• 分支来自不同 fork：官方规则不支持跨 fork 的 stack 管理。
• 团队主要依赖 GitHub Desktop 做日常操作：当前 Stacked Pull Requests 不兼容 GitHub Desktop 工作流。
• 仓库的 CI 每次都要执行耗时很久的全量任务：先确认重复检查的额外成本，再决定要不要分层优化。

可以先选一个三层、每层改动量很小的功能做试点，观察审查等待时间、重复 CI 次数、返工冲突概率和合并队列的实际表现。核心目标是降低大 PR 的认知负担，不是让分支网络变得更难维护。

常见问题

Stacked Pull Requests 是 Git 的新分支类型吗？

不是。它底层仍然由普通分支、提交和 PR 组成，GitHub 只是额外记录了它们的层级依赖关系，配套提供了创建、重排、审查和合并的相关支持。

中间层 PR 会不会跳过 main 的检查？

不会。官方规则要求每层都按 stack 根分支的保护规则和必需检查评估，中间层没有免检权限。

只想合并 stack 的前两层可以吗？

可以从底部合并到指定的中间层，上方 PR 会继续保留并自动调整目标分支；想要完整合并的话从最上层落地整个 stack 就可以。

GitHub Desktop 能管理 stack 吗？

目前不支持 GitHub Desktop。可以用 GitHub 网页端或者 GitHub CLI 的 gh stack 扩展操作，具体命令以当前官方文档为准。

落地前的一张检查清单

先动手画出「哪一层依赖哪一层」的关系图，再决定要不要启用 stack。确认所有分支都属于同一个仓库；为每层写清楚独立的验收点；检查 CI 能不能承受多层重复触发；最后在小功能上完整跑一次从底部到顶部的合并流程。如果这些条件都满足，Stacked Pull Requests 才能把大改动拆成更容易读懂的逻辑链路，而不是新增一套需要额外维护的分支流程。