注: pull request のマージ キュー機能は現在、限定的なパブリック ベータ版であり、変更される可能性があります。
マージ キューについて
マージ キューを使用すると、必要なすべてのブランチ保護チェックに合格することを保証しつつ、pull request がビジー状態のターゲット ブランチにマージされる速度を上げることができます。
pull request が必要なすべてのブランチ保護チェックに合格すると、リポジトリへの書き込みアクセス権を持つユーザーは、その pull request をマージ キューに追加できます。
マージ キューでは、GitHub Actions を使用できます。 詳細については、「GitHub Actions」を参照してください。
pull request 変更の有効性を検証する特別なプレフィックスを付け、一時的なブランチがマージキューによって作成されます。 次に、pull request の変更は、base_branch
の最新バージョンとキューでそれに先行する変更と共に、merge_group
にグループ化されます。 GitHub では、base_branch
のブランチに必須のチェックで合格すると、これらの変更がすべてマージし、base_branch
が作られます。
マージ方法について詳しくは、「pull request のマージについて」を参照してください。
注:
- マージキューは、ブランチ名パターンにワイルドカード文字 (
*
) を使用するブランチ保護ルールで有効にできません。 - マージ キューは、マージを続ける前に、必要なチェックが報告されるまで待機します。 マージ キューが必要な場合は、マージ グループ イベントをトリガーして報告するように、CI の構成を更新する必要があります。
pull request をターゲット ブランチの最新バージョンとグループ化し、キュー内でその前に変更した後、必要な状態チェックが失敗した場合、またはベース ブランチと競合した場合、GitHub によって pull request がキューから削除されます。 pull request タイムラインには、その pull request がキューから削除された理由が表示されます。
GitHub Actions を使ってマージ グループのチェックをトリガーする
merge_group
イベントを使って、pull request がマージ キューに追加されたときに GitHub Actions ワークフローをトリガーできます。 これは pull_request
イベントや push
イベントとは異なるイベントであることに注意してください。
ターゲット ブランチの保護で必要なチェックを報告するワークフローは、次のようになります。
on:
pull_request:
merge_group:
詳細については、「ワークフローをトリガーするイベント」を参照してください。
他の CI プロバイダーを使ってマージ グループのチェックをトリガーする
他の CI プロバイダーを使う場合、特別なプレフィックス gh-readonly-queue/{base_branch}
で始まるブランチが作成されたときに実行するように CI 構成を更新する必要がある場合があります。
マージキューの管理
リポジトリ管理者は、ベース ブランチの保護ルールでブランチ保護設定 [Require merge queue] (マージ キュー必須) を有効にして、マージ キューを必須にできます。
マージ グループ サイズの設定について
マージ キューのマージ グループ サイズを構成できます。これにより、各マージ グループに含まれる pull request の数が決まります。 状態チェックの失敗やマージの競合がない場合、既定の "小" マージ グループ サイズを選ぶと、2 つの pull request を含むグループが作成されます。 グループごとにさらに多くの pull request をグループ化したい場合は、"中" マージ グループ サイズを選んで、それぞれに 5 つの pull request が含まれるグループを作成できます。
マージキュー保護設定を有効にする方法については、「ブランチ保護ルールの管理」を参照してください。
参考資料
- 「pull request とマージキューのマージ」
- 「About protected branches」 (保護されたブランチについて)