PuppyIP 资源中心
AI 开发与协作 6 分钟 发布于 2026-11-11

GitHub 堆叠 PR 如何合并：自底向上与审批保留条件

从最低的未合并 PR 开始向上合并：选择中间层也会包含它下方未合并的 PR，上方 PR 则保持打开并自动改为以堆栈基线为目标。合并前核对本次合并范围的审批、检查、线性历史与基线分支规则；Rebase stack 仅在差异未改变时保留审批。

GitHub 堆叠拉取请求 PR 审查 Rebase stack AI 开发协作

服务对象与地域限制

PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。

代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。

本文要点

  • 堆叠 PR 必须从最低的未合并层向上合并；选中中间层会连同其下方未合并 PR 一起合并。
  • 分支应按依赖顺序串接，让每个 PR 只展示相对下层的独立变更；所有堆叠分支必须位于同一仓库。
  • 合并门槛由底层 PR 的目标分支决定；下层 PR 需要已获批且检查通过，整栈还需线性历史，并满足基线分支保护规则。
  • Rebase stack 会生成签名替代提交；仅在某个 PR 的差异未改变时保留其审批，即使仓库启用了过期审批撤销规则。

从最低的未合并 PR 开始向上合并

GitHub 堆叠 PR 必须从最低的未合并层向上合并。GitHub 允许合并一个 PR，也允许合并一段连续的 PR，但每次选择的范围都必须从最低未合并层开始。因此，选中中间 PR 会把它下方尚未合并的 PR 一起纳入；上方 PR 保持打开，并自动改为以堆栈基线为目标。选择顶层 PR 则会合并整个堆栈。合并前先查看堆栈图，确认本次会一起进入基线的层。

假设有一个三层示例：PR #1 将共享类型合入 main，PR #2 在类型分支之上增加 API 端点，PR #3 再在 API 分支之上增加界面。如果只有 #1 和 #2 已准备好，选择 #2 会按自底向上的顺序合并两者；#3 仍保持打开，之后会以 main 为目标。这个例子用于说明规则，不要求团队采用这些分支名称。

按依赖顺序组织分支和审查层

让每个分支都包含它所依赖的工作。底层 PR 指向堆栈的主干分支，通常是 main 等默认分支，也可以是发布分支；之后的每个 PR 都以其正下方 PR 的分支为目标。把共享类型或数据库结构等基础改动放在较低层，再把依赖它们的 API 和界面改动放在上层。保持每层聚焦，方便审查者在依赖上下文中判断该层变更。任何一层所需的前置改动都必须已经在本层或更低层，不能只存在于更高层。

堆叠分支必须位于同一仓库；跨 fork 堆叠不受支持，GitHub Desktop 也不支持堆叠 PR。GitHub 网页上的堆栈图会显示层级和状态，帮助团队按依赖关系审查变更，包括由 AI agent 生成后提交审查的贡献。

检查整栈的合并门槛

合并条件针对整栈，而不只是当前打开的 PR。堆栈底层 PR 的目标分支决定所有层的合并要求。某一层要合并前，它下方的所有 PR 都必须已获批准且检查通过；整栈必须保持线性历史；当前 PR 还必须满足堆栈基线的分支保护规则。CODEOWNERS 审批等规则会应用于堆栈中的每个 PR，包括中间层。由默认分支 PR 触发的 CI 检查也会应用于整栈中的所有 PR。

分别审查每层相对于下方分支的差异，再查看整栈状态。顶层 PR 的审批或通过状态不能绕过下层未满足的要求。若缺少必需检查、审批或基线规则，应沿用仓库已有的审查与 CI 流程处理后再合并。

分支变化后先执行 Rebase stack

当前 PR 下方的改动可能让堆栈不再保持线性历史。例如，有人向较低分支推送了新提交，或堆栈尚未合并时主干分支已经前进。GitHub 在合并框中显示 Rebase stack 按钮时，表示需要先重放堆栈。该操作会更新依赖分支，使其历史重新跟随基线，然后才能合并。

GitHub 会在堆栈变基时创建带签名的替代提交。如果某个 PR 的差异没有改变，GitHub 会保留该 PR 的审批，即使仓库启用了撤销过期审批的规则。审批保留以差异未变化为条件；如果变更了差异，仍应按团队流程重新审查。部分合并完成后，下一个未合并 PR 会自动变基并直接指向堆栈基线，成为接下来审查和合并的最底层。

核对功能范围与合并队列行为

GitHub 于 2026 年 10 月 6 日宣布堆叠 PR 正式可用，并说明所有 github.com 方案均可使用。公告表示该功能将纳入未来的 GitHub Enterprise Server 版本，但没有指出已发布的 GHES 版本；请核实实际使用的实例是否支持。文档还介绍了 GitHub 网页、GitHub CLI、GitHub Mobile 及程序化集成支持。GitHub CLI 的 gh stack 扩展用于本地堆栈工作流。

堆叠 PR 支持合并队列，整栈会按正确的先后顺序加入队列；如果某个 PR 被移出或弹出队列，它上方的 PR 也会一并移出。通过 REST API 合并堆栈时，GitHub 要求使用面向堆栈的异步合并 API。不要猜测端点或假定普通单 PR 合并流程适用于堆栈。功能本身不会替代仓库的审批、检查或发布要求。

资料来源

常见问题

堆叠 PR 支持哪些合并方式？

堆叠 PR 支持 merge commit、squash 和 rebase。生成的提交历史等同于从底层开始逐个合并每个 PR。

整个堆栈合并完成后，可以继续在原堆栈上追加 PR 吗？

不可以，所有 PR 合并后该堆栈就完成，不能继续扩展。若使用 GitHub CLI 的 gh stack submit 提交新的上层分支，GitHub CLI 会从主干分支开始一个新堆栈。

继续阅读