向组织推出堆积拉取请求

堆积拉取请求有助于组织保持评审质量，因为团队在小型可审阅层中提供大更改，同时保持所需的评审和状态检查到位。

谁可以使用此功能？

Enterprise and organization owners

在本文中

注意

堆积拉取请求处于 公开预览 其中且可能会更改。

堆叠拉取请求可让开发人员将大型更改分解成一系列基于彼此构建的小型集中拉取请求。 此方法可帮助组织保持评审质量，因为开发人员生成更多代码，包括与其他 Copilot 编码代理。

堆积拉取请求 不需要设置或启用。 如果团队已使用拉取请求，他们可以立即创建堆栈。 以下步骤可帮助你准备现有控件并支持流畅的推出，而不是启用功能。

本教程可帮助你确定堆积拉取请求是否符合组织，确保基础已到位，试点工作流，支持采用和更新编程工具。 若要基本了解堆积拉取请求，请参阅 关于堆积拉取请求。

1.确定堆积拉取请求是否适合

在投资推出之前，请使用此快速自我检查：

  • 你的团队是否生成大量代码，无论是自己还是与其他 Copilot 编码代理？
  • 你的团队是否处理大型功能，尤其是在 monorepos 中，难以拆分为独立的拉取请求？

如果两者都描述了你的团队，堆积拉取请求可以帮助他们在较小的单元中提交依赖性更改，而无需等待每个拉取请求合并，然后再启动下一个请求，只要其工作符合一个约束：堆栈中的每个拉取请求都必须位于同一存储库中，遵循单个线性分支链。 堆栈不能包含分叉或分支结构，因此严重依赖分叉供稿的团队现在应将这些贡献保留在堆栈之外。

2. 确保基础已到位

堆栈中的每个拉取请求都根据 堆栈的基 数（通常 main）而不是直接面向的分支进行评估。 现有的分支保护规则或规则集和 CI 工作流会自动应用：

  • 针对堆栈中每个拉取请求的堆栈基分支强制实施所需的评审、所需的状态检查和 CODEOWNERS。
  • GitHub Actions针对存储库默认分支的事件触发pull_request的工作流针对堆栈中的每个拉取请求运行，因此现有 CI 配置无需更改。
  • 如果要专门为堆积拉取请求自定义工作流行为，则堆栈元数据可通过工作流表达式 github.event.pull_request.stack获取。 由于工作流每次拉取请求在堆栈中运行一次，因此团队可以使用此元数据来限制昂贵的作业并减少 CI 使用率。 有关详细信息，请参阅 优化堆积拉取请求的 CI。

值得考虑的一个可选补充：如果开发人员在创建堆栈后需要重新排序拉取请求而不将其解散，请gh stack采用扩展。GitHub CLI 就地重新排序需要 gh stack modify;在网站上 GitHub ，开发人员必须取消拉取请求，并按所需顺序重新创建堆栈。

堆栈中每个拉取请求合并后也会自动关闭。 如果团队在合并堆栈的顶部添加新分支并运行 gh stack submit，CLI 会启动具有相同基分支的新堆栈。 它不会扩展原始内容。 想要在一组更改中继续工作的团队应计划让堆栈保持打开状态，直到完成所有工作。

有关规则和要求的完整列表，请参阅 堆积拉取请求。

3. 使用小组试点

选择一小部分开发人员，他们自己或通过 Copilot 其他编码代理生成大量代码。 要求该组使用飞行员的实际代表性功能，而不是一次性示例。

若要创建第一个堆栈，请引导用户到 堆积拉取请求快速入门。 试点后，请从开发人员和审阅者那里收集有关以下方面的反馈：

  • 堆栈规划如何适应其现有工作流，以及开发人员是否需要就地重新排序，这需要 gh stack 扩展
  • 评审流现在是否觉得不同，堆栈中的每个拉取请求都带有自己的所需评审和状态检查
  • 他们遇到的任何支持或文档差距

4. 推出和支持采用

试点结束后，与团队共享有关创建、评审、管理和合并堆栈的日常指导： 堆积拉取请求。

如步骤 2 中所述，当开发人员需要重新排序堆栈而不解散堆栈时，建议 gh stackGitHub CLI 扩展。 不使用本地 CLI 工具的团队可以取消堆栈，并在网站上的所需顺序 GitHub 重新创建堆栈。

生成大量 AI 生成的代码（步骤 1 中适合信号之一）的团队可以找到有关 在 AUTOTITLE 中对编码代理进行堆栈更改的指导。

5.更新编程工具

若要持续采用，请查看以编程方式创建、合并或跟踪拉取请求的任何内部工具、机器人或仪表板，并更新它们以考虑堆栈。

如果你的组织提供内部 CLI 或其他开发人员工具，则可以使用 Stacks API 将堆栈创建和管理集成到这些现有工具中，而无需开发人员采用 gh stack。

重要

合并堆积拉取请求需要异步合并 API。 旧拉取请求合并终结点无法合并堆栈。 如果组织以编程方式合并拉取请求（例如，通过内部工具或 ChatOps 机器人），请在推出堆叠拉取请求之前更新该工具以调用支持堆叠拉取请求和常规拉取请求的异步合并 API。 请参阅“用于拉取请求的 REST API 终结点”。

你可能还希望以编程方式跟踪堆栈活动，例如跨仪表板、机器人或内部工具。

  • REST API：API 返回的每个拉取请求都包括一个 stack 对象，当它属于堆栈时，它显示堆栈的数量、大小、拉取请求的位置以及堆栈的基分支。 专用堆栈 API （GET /repos/{owner}/{repo}/stacks） 还会列出存储库中的每个堆栈，或包含给定拉取请求的特定堆栈。 请参阅“堆积拉取请求 API 和 Webhook”。
  • Webhook： pull_request 每当拉取请求属于堆栈时，Webhook 有效负载都包含相同的 stack 对象。 首次将拉取请求添加到堆栈时，将触发专用 stacked 操作，因此你可以对堆栈形成的那一刻做出反应。

在这两种情况下， stack 该字段用于 null 独立拉取请求，因此不需要堆栈的现有集成将继续保持不变。