Skip to main content
我们经常发布文档更新,此页面的翻译可能仍在进行中。 有关最新信息,请访问英语文档

管理合并队列

可以通过在存储库中为拉取请求启用合并队列来加快开发速度。

谁可以使用此功能

People with admin permissions can manage merge queues for pull requests targeting selected branches of a repository.

拉取请求合并队列在组织拥有的任何公共存储库中可用,或在使用 GitHub Enterprise Cloud 的组织拥有的专用存储库中可用。 有关详细信息,请参阅“GitHub 的产品”。

注意: 拉取请求合并队列功能目前为公开测试版本,可能会发生更改。

关于合并队列

合并队列可以提升拉取请求合并到繁忙的目标分支的速度,同时确保所有必需的分支保护检查都通过。

拉取请求通过所有必需的分支保护检查后,对存储库具有写入访问权限的用户可以将该拉取请求添加到合并队列。

合并队列可以使用 GitHub Actions。 有关详细信息,请参阅“GitHub Actions文档”。

合并队列创建具有特殊前缀的临时分支来验证拉取请求更改。 然后,使用最新版本的 base_branch 将拉取请求中的更改分组到 merge_group,与队列中位于其之前的更改一样。 一旦 base_branch 的分支保护所需的检查通过,GitHub Enterprise Cloud 会将所有这些更改合并到 base_branch 中。

有关合并方法的信息,请参阅“关于拉取请求合并”。

注意:

  • 在分支名称模式中使用通配符 (*) 的分支保护规则无法启用合并队列。
  • 合并队列将等待报告所需的检查,然后才能继续合并。 必须更新 CI 配置,以在需要合并队列时触发和报告合并组事件。

在将拉取请求与目标分支的最新版本分组并在队列中提前更改后,如果所需的状态检查失败或与基本分支冲突,GitHub Enterprise Cloud 将从队列中删除拉取请求。 拉取请求时间线将显示从队列中删除拉取请求的原因。

通过 GitHub Actions 触发合并组检查

将拉取请求添加到合并队列时,可以使用 merge_group 事件触发 GitHub Actions 工作流。 请注意,这是与 pull_requestpush 事件不同的事件。

注意: 如果存储库使用 GitHub Actions 对存储库中的拉取请求执行必要的检查,则需要更新工作流以将 merge_group 事件作为附加触发器包含在内。 否则在将拉取请求添加到合并队列时不会触发状态检查。 合并将失败,因为没有报告必要的状态检查。

报告目标分支保护所需的检查的工作流如下所示:

on:
  pull_request:
  merge_group:

有关详细信息,请参阅“触发工作流的事件”。

通过其他 CI 提供程序触发合并组检查

使用其他 CI 提供程序时,可能需要更新 CI 配置,以在创建以特殊前缀 gh-readonly-queue/{base_branch} 开头的分支时运行。

管理合并队列

存储库管理员可以通过在基本分支的保护规则中启用分支保护设置“需要合并队列”来要求合并队列。 有关详细信息,请参阅“管理分支保护规则”。

启用“需要合并队列”后,还可以使用以下设置:

  • 合并方法:选择合并排队的拉取请求时要使用的方法:合并、变基或压缩。

  • 生成并发:选择要生成的最大拉取请求数(1 到 100 之间)。 此设置限制可以同时运行 CI 检查的已排队拉取请求的数量。

  • 合并限制:选择要合并到单个组中的拉取请求的最小数量和最大数量(1 到 100 之间),并选择一个超时时间,在该时间之后队列应停止等待更多条目并与少于最小数量的拉取请求合并。

  • 仅合并非失败的拉取请求:此设置决定合并队列如何形成要合并的拉取请求组。

    如果选中该设置,则只有通过了所需 CI 检查的拉取请求才能添加到组中。 如果要维护每个提交都处于良好状态的历史记录,或者如果为不同的拉取请求运行不同的检查集,这将很有用。

    如果未选中该设置,则可以将未通过所需检查的拉取请求添加到组中,前提是该组中的最后一个拉取请求已通过所需检查。 如果组中的最后一个拉取请求已通过所需的检查,这意味着合并组中的更改组合集已通过检查。 如果发生间歇性测试失败,但不希望假阴性阻碍队列,则不选中此复选框可能很有用。

  • 状态检查超时:选择队列等待 CI 响应的时间,超过该时间则假定检查未通过。

延伸阅读