# 关于堆积拉取请求 将大型代码更改分解成一系列较小的依赖拉取请求，你可以独立查看和合并。 > \[!NOTE] 此功能以公共预览版提供，可能会发生更改。 ## 关于堆积拉取请求 堆叠拉取请求是同一存储库中的两个或多个拉取请求，其中： * 第一个或底部拉取请求面向堆栈的中继，通常是存储库的默认分支，例如 `main`，尽管它可以是任何分支，例如发布分支。 * 每个后续拉取请求都以拉取请求的分支为目标。 ```text ┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top ┌── feat/api-endpoints → PR #2 (base: feat/auth-layer) ┌── feat/auth-layer → PR #1 (base: main) ← bottom main (default base branch) ``` 堆积分支形成一个依赖项链，其中每个分支都基于下面的分支构建。 基础性更改（如共享类型和数据库架构）位于较低分支中，依赖于它们的代码（如 API 路由和 UI 组件）位于更高的分支中。 堆栈中的每个拉取请求都表示一个离散的、可查看的一个或多个提交更改。 可以单独查看和循环访问每个拉取请求，每个请求仅显示其层的差异及其分支与其下方的分支之间的更改。 **关键原则：** 如果一个层中的代码依赖于另一层中的代码，则依赖项必须位于同一分支或较低分支中。 在开始不同的关注时创建新分支，具体取决于到目前为止已生成的内容。 例如，从后端切换到前端工作时，请从核心逻辑移动到测试，或者当前分支已足够大才能查看。 ## 为何使用 GitHub 堆积拉取请求 ### 完成一个更改并直接移动到下一个 堆叠拉取请求允许在仍处于打开状态的拉取请求的基础上打开一个新的拉取请求。 在大型项目中，下一次更改可能取决于尚未合并的工作。 你可以继续生成，而不是等待它与堆栈合并。 当堆栈中的每个拉取请求包含一个重点更改时，审阅者将看到每个层的小差异，而不是大型拉取请求。 较小的拉取请求更快审查，不太可能被浏览，不太可能过时并开发合并冲突。 ### 适合大容量开发 一次生成大量代码（通常使用 AI 代理）时，堆栈会为每个更改提供一个可去的地方。 代理完成一个任务，然后启动生成它的下一个任务。 该序列直接映射到堆栈：每个任务一个拉取请求，每个请求都基于以下请求。 堆栈允许显式记录这些依赖项，而不是将不相关的更改合并到单个分支中。 ### 使用堆叠拉取请求的优点 GitHub 如果没有堆积拉取请求，将重大更改分解为较小的依赖拉取请求会创建额外的工作： * **分支管理。** 跨依赖拉取请求重新分组和保持分支同步非常繁琐且容易出错。 * **规则和 CI。** 分支保护规则和 CI 检查通常仅触发链中底部拉取请求，因此很难知道其余请求的真实状态。 * **查看上下文。** 从堆栈的其余部分查看上下文中的单个更改可以减少评审质量。 堆积拉取请求通过将拉取请求链视为连接单元来解决这些问题，同时使每一层保持较小且专注。 #### Rebasing Rebasing 是处理堆栈的最棘手部分，并 GitHub 自动处理它。 可以从拉取请求触发服务器端级联 rebase，或使用扩展`gh stack`运行本地级联存储库GitHub CLI。 在堆栈底部合并拉取请求时，其余分支会自动重新定基，以便下一个拉取请求面向默认基分支。 ## 在何处可以使用堆积拉取请求 堆积拉取请求在以下项中可用： * GitHub CLI * GitHub 网站 * GitHub Mobile * 通过 Webhook、REST API 和 GraphQL 进行编程支持 * 对于代理，通过 `gh-stack` 技能 > \[!NOTE] > > * 堆积拉取请求要求所有分支都位于同一存储库中。 不支持跨分支堆栈。 > * 不支持堆叠拉取请求 GitHub Desktop。 ### 在 GitHub CLI 中 处理 `gh stack` 本地开发工作流的扩展 GitHub CLI 。 可以按正确的依赖项顺序创建和跟踪分支，使分支保持基数、推送分支、创建和链接拉取请求，并在层之间导航。 请参阅“[堆积拉取请求 CLI 命令](/zh/enterprise-cloud@latest/pull-requests/reference/stacked-prs-cli-commands)”。 ### 在网站上GitHub 当拉取请求是堆栈的一部分时，你将看到： * 拉取请求顶部的堆栈图标 ，其中包含一个数字，指示正在查看哪个层。 * 堆栈映射显示在合并框中。 它显示堆栈中的每个拉取请求及其状态，并允许你单击一次导航到任何层。 中继（默认基分支）位于底部，堆栈中的每个拉取请求都面向其下方拉取请求的分支。 ### 通过 Webhook、REST API 和 GraphQL 进行编程支持 堆积拉取请求以编程方式可用，因此你可以将它们集成到自己的工具、自动化和仪表板中： * **Webhook 在**事件有效负载中包含`stack`一个`pull_request`对象，因此当拉取请求联接、移动或离开堆栈时，自动化可以做出响应。 * **REST API** 读取拉取请求的堆栈成员身份，并提供用于列出、创建、扩展和解散堆栈的终结点。 * **GraphQL API** 在拉取请求上公开只读 `stack` 字段，用于查询堆栈及其拉取请求的位置。 ## 规则、CI 和合并 ### 规则和 CI 强制执行 堆积拉取请求支持 GitHub Actions 工作流。 堆栈中任何拉取请求的合并要求通常由底部拉取请求的基分支 `main`确定。 * 分支保护规则（如 CODEOWNER 审批）在堆栈中的每个拉取请求上强制实施，即使是不直接面向默认分支的中间堆栈拉取请求。 * 默认分支上拉取请求触发的 CI 检查会针对堆栈中的所有拉取请求运行，而不仅仅是底部请求。 这可确保堆栈的每个层都满足相同的质量条，然后才能合并。 ### 合并 可以合并整个堆栈、单个拉取请求或跨多个拉取请求的堆栈的一部分。 整个堆栈不需要一次合并，但拉取请求必须从下到上合并。 * 通过合并顶部拉取请求一次性合并整个堆栈。 它附带的每个拉取请求。 * 通过合并中间堆栈拉取请求合并堆栈的一部分。 它下方的拉取请求也合并，上面的拉取请求保持打开状态，并自动重新定位堆栈的基础分支。 堆栈支持合并提交、squash 和 rebase 合并方法，并且它们具有合并队列感知功能。 生成的提交历史记录与逐个合并每个拉取请求相同，从底部开始。 > \[!NOTE] > 如果通过 API 合并并想要使用堆叠拉取请求，则需要更新才能使用新的堆栈合并 API。 请参阅“[用于拉取请求的 REST API 终结点](/zh/enterprise-cloud@latest/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously)”。 ## 后续步骤 * [堆积拉取请求快速入门](/zh/enterprise-cloud@latest/pull-requests/get-started/stacked-prs-quickstart?utm_source=docs-pr-stacks-quickstart\&utm_medium=docs\&utm_campaign=stacked-prs-gtm-public-preview-2026) * [向组织推出堆积拉取请求](/zh/enterprise-cloud@latest/pull-requests/tutorials/roll-out-stacked-prs?utm_source=docs-roll-out-pr-stacks\&utm_medium=docs\&utm_campaign=stacked-prs-gtm-public-preview-2026)