merge-open-prs

オープンな PR をマージする

オープンな PR をスナップショットし、その一覧を作業対象とします。各 PR をフォージ経由で一件ずつ、後続の PR をデフォルトブランチに更新できる順序でマージしてください。独立した PR をまとめてスタックにしたり、作業対象を一つの統合 PR に置き換えたりしないでください。

基本ルール：

• 作業対象は増やしません。 スナップショット後に作成された PR は無視します。マージするたびに、残りのオープンな PR と作業対象を照合してください。対象外の PR は決してマージしないでください。
• 鮮度の要件はリポジトリのマージポリシーに従います。 マージするたびに、残りの PR を再確認してください。ブランチを更新するのは、競合がある場合、依存関係が変更された場合、またはリポジトリで鮮度が明示的に求められている場合に限ります。ベースブランチが移動しただけでは、変更のない PR のチェックが成功済みであることは無効になりません。
• すべての PR はフォージ経由で取り込みます。 ローカルのデフォルトブランチにマージしてプッシュしたり、デフォルトブランチへ直接プッシュしたりしないでください。ローカルの git 操作は、PR 自身のブランチでのみ、一時的なワークツリー内で行い、作業後にそのワークツリーを削除してください。

1. 作業対象をスナップショットする

gh api --paginate 'repos/{owner}/{repo}/pulls?state=open&per_page=100' \
  --jq '.[] | {number,title,headRefName:.head.ref,headRefOid:.head.sha,baseRefName:.base.ref,isDraft:.draft}'

すべてのページを読み取ってください。ユーザーが特定の PR を指定した場合は、それらが作業対象です。そうでない場合は、すべてのオープンな PR が対象です。番号、head SHA、head ブランチを記録してください。

明らかに単独の PR である場合を除き、ファイルの重複マップを作成してください。

gh pr view <n> --json files,headRefName,headRefOid,baseRefName,isDraft,reviewDecision,statusCheckRollup,isCrossRepository,maintainerCanModify
gh pr diff <n>

未準備の PR（ドラフト、変更要求あり）も作業対象に残します。マージ可能な状態にしてください。対象から外さず、ユーザーの指示なしに、回答されていない変更要求を無視してマージしないでください。

作業対象が空の場合は、停止してください。

2. マージ順を決める

ファイルが重複しない PR は、どの順序でもテキスト上の競合が起きないため、意味と検証のしやすさを考慮して順序を決めてください。優先順位は次のとおりです。

• 小規模で独立した PR を先にします（設定の調整、依存関係の更新、後続の PR の検証に役立つツールなど）。
• 基盤となるものを依存するものより先にします。ある PR が別の PR で追加されるものを呼び出す場合は、依存先を先にマージしてください。
• 共有状態に関わる PR は最後にします。バージョン定数、マイグレーション番号、チェックイン済みの生成物などは、すでに取り込まれたすべての変更に重なります。
• それ以外は、影響範囲の小さいものから順にします。

ある PR のベースが作業対象の別の PR である場合は、親を先にマージしてください。既存のベースブランチの連鎖は、その順序が適切であることを示しています。ユーザーが指定した順序を優先してください。作業を始める前に、マージ順と各 PR の理由を一行ずつ示してください。

3. マージ条件を確認する

gh repo view --json mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed
gh api repos/{owner}/{repo}/branches/{branch}/protection   # may 404 even when gated
gh api repos/{owner}/{repo}/rulesets

gh pr merge では、リポジトリのマージ方法を明示的に指定してください。ルールセットと従来の保護設定は別々に確認し、必須チェック、必須レビュー、厳格な最新化ポリシーを調べてください。

4. 各 PR をマージする

一時的な worktree で作業します。各 PR を順番に処理します。

1. Fetch します。デフォルトブランチの先端を記録します。
2. この PR のベースが、同じ作業セット内の別の PR である場合は、その親 PR がマージされるまで待ちます。GitHub 側で変更されていない場合は、gh pr edit <n> --base <default-branch> でベースを変更します。
3. この PR で、リポジトリのポリシーに基づくベース更新が必要か確認します。resolve-pr-conflicts を使って、ブランチ上でコンフリクトを解決します。isCrossRepository と maintainerCanModify が、更新するリモートに合っていることを確認します。すでに許可されている場合を除き、自分が所有していないブランチを書き換える前に明示的な承認を得て、すべての書き換えを報告します。
4. 必要な更新を Push します。Draft は処理を妨げます。ユーザーの指示に従い、意図的な Draft である場合は gh pr ready を先に実行します。
5. この PR について、リポジトリ独自のチェック（ビルド、フォーマット、Lint、および変更の影響範囲に関するテスト）で検証します。babysit を使い、この PR で必須のチェックがすべて成功するまで待ちます。現在のデフォルトブランチでは PR をマージ可能にできない場合は、停止して確認を求めます。
6. head SHA、マージ可能性、リポジトリのゲートをもう一度確認します。head が新しくなった場合は、その head 自身でチェックに合格する必要があります。リポジトリのポリシーまたは新たなコンフリクトによって必要になった場合に限り、ベースの移動後にもう一度更新します。その後、次を実行します。

gh pr view <n> --json headRefOid
gh pr merge <n> <verified-method-flag> --delete-branch --match-head-commit <sha>

マージキューは PR をキューに登録し、独自の方法を選択します。次の PR を開始する前に、マージされるまで待ちます。

チームメイトが作業セットのブランチに Push した場合は、その変更を確認して保持し、新しい head を検証します。所有権や意図する解決方法が不明な場合に限り、確認を求めます。PR がクローズされるとマージできなくなります。そのことを報告し、独立した PR の処理を続けます。誰かが作業セットの PR をマージした場合は、残りの PR の処理を続けます。

--admin は、明示的な承認がある場合に限り使用し、報告で明らかにします。

最後のマージ後、デフォルトブランチでリポジトリが必須とする統合結果を検証します。CI の実行結果で必要な根拠が得られる場合は、それを使用します。カバーされていないリスクについては、追加のローカルチェックを実行します。worktree を削除します。

5. 報告

1. 作業セットの PR、後から追加されたため対象外とした PR、ファイルが重複していたかどうか。
2. マージ順と、それぞれの理由。マージしなかった作業セットの PR と、その理由。
3. 解決したコンフリクト、書き換えたブランチ、バイパスの有無。
4. デフォルトブランチの移動と、その対応内容。
5. 実行した内容と成功したチェック。最後のデフォルトブランチでの結果も含めます。
6. 最終的なデフォルトブランチの SHA と、未解決のまま残っている PR。

リクエストにリリースが含まれる場合は、マージしたコミットで CI が成功した後に $tag-release を使用します。