GitHubでブランチ保護をまとめてrulesetへ移行：変換前に確認すること

mainへの直接変更を防いだり、テストが通るまで取り込めなくしたり。GitHubのブランチ保護を使っているチーム向けに、まとめて移行する操作が追加されたよ。新しい設定を増やす前に、今の保護がどう引き継がれるかを確認してみよう。

何をまとめて変換できる？

10月20日の公式告知は、リポジトリ内のブランチ保護ルールを一度にrulesetへ変換する機能を紹介している。rulesetは、どのブランチに、どんな操作条件を適用するかをまとめる仕組み。従来の単一ルールの変換を広げた更新だね。

対象はrulesetが利用できるリポジトリ。契約やリポジトリの条件によって利用範囲が異なるので、自分の画面と公式の変換手順を照らし合わせよう。

作成前のプレビューで見ること

リポジトリのSettingsからRulesetsを開き、Import branch protection rulesへ進む。変換結果を確認する画面では、作られるruleset、既存rulesetでカバーされるルール、元の振る舞いを保つため一つの保護から複数が作られるケースを確認できる。適用状態と作成対象も選べるよ。

作成後は、元のブランチ保護を残すか削除するかを選ぶ。操作が一括になっても、削除の判断まで急ぐ必要はないね。

先に書き出しておく確認表

ここからは編集部の移行準備案。移行前の設定を、次のような表にして残しておくと比較しやすい。

チーム独自の運用は、設定名だけで判断しないようにしよう。例えば自動更新用のアプリを例外にしているなら、そのアプリがいつ、どのブランチを更新するかも一緒に記録する。

小さなPRで移行後の振る舞いを確認

1. 元の設定と、変換プレビューを比較する。
2. 必須チェックが動く小さなPRを用意する。
3. 条件を満たす前と満たした後で、マージ可否を確認する。
4. 自動化に使うアプリの処理も確認する。
5. 元ルールを削除するかは、確認結果とチームの方針で判断する。

保護の変更はチーム全体の作業に影響する。操作担当と、困ったときに戻す設定を決めてから進めたいね。自動化の設定値も整理するなら、GitHub Actionsのシークレットと変数も合わせて確認してみよう。