ルールセットについて
ルールセットは、リポジトリに適用されるルールの名前付きリストです。 ルールセットを作成して、リポジトリ内の特定のブランチとタグをユーザーが操作する方法を制御できます。 どのユーザーが特定のブランチにコミットをプッシュできるか、どのユーザーがタグを削除または名前変更できるかといったことを制御できます。 たとえば、リポジトリの feature ブランチに対して、署名されたコミットを必須とし、リポジトリ管理者を除くすべてのユーザーの強制プッシュをブロックするルールセットを設定できます。
作成するルールセットごとに、リポジトリ内のどのブランチまたはタグにルールセットを適用するかを指定します。 fnmatch 構文を使用して、特定のブランチとタグを対象とするパターンを定義できます。 たとえば、パターン releases/**/* を使用すると、リポジトリ内の名前が文字列 releases/ で始まるすべてのブランチを対象とすることができます。 fnmatch の構文について詳しくは、「リポジトリのルールセットの作成」を参照してください。
ルールセットを作成するときに、特定のユーザーがルールセットの中のルールをバイパスすることを許可できます。 これは、リポジトリ管理者などの特定のロールを持つユーザー、または特定のチームや GitHub Apps にすることができます。
ルールセット、保護されたブランチ、保護されたタグについて
ルールセットは、リポジトリのブランチ保護ルールおよびタグ保護ルールと連携して機能します。 ルールセットで定義できるルールの多くは保護ルールに似ており、既存の保護ルールをオーバーライドせずにルールセットの使用を開始できます。
ルールセットには、ブランチとタグの保護ルールよりも優れた次の利点があります。
- 保護ルールとは異なり、複数のルールセットを同時に適用できるため、リポジトリ内のブランチまたはタグを対象とするすべてのルールが、誰かがそのブランチまたはタグを操作したときに評価されることを確信できます。 詳しくは、「ルールの階層化について」を参照してください。
- ルールセットには状態があるため、ルールセットを削除しなくても、リポジトリでどのルールセットをアクティブにするかを簡単に管理できます。
- リポジトリへの読み取りアクセス権を持つユーザーは、リポジトリのアクティブなルールセットを表示できます。 これは、開発者がルールに抵触した理由を理解できること、または監査担当者がリポジトリへの管理者アクセス権を必要とせずに、リポジトリのセキュリティ制約を確認できることを意味します。
さらに、GitHub Enterprise プランの Organization の場合、ルールセットを使用して次のことができます。
- Organization 内の複数のリポジトリを対象とするように、Organization レベルでルールセットをすばやく設定します。 詳しくは、「Organization 内のリポジトリのルールセットを管理する」を GitHub Enterprise Cloud のドキュメントで参照してください。
- コミット メッセージや作成者のメール アドレスなど、リポジトリに入力するコミットのメタデータを制御する追加のルールを作成します。 詳しくは、「ルールセットで使用できるルール」を GitHub Enterprise Cloud のドキュメントで参照してください。
- ルールセットをアクティブにする前に "評価" 状態を使用してテストし、分析情報ページを使用して、どのユーザー アクションがルールの影響を受けているかを確認します。 詳しくは、「リポジトリのルールセットの管理」を GitHub Enterprise Cloud のドキュメントで参照してください。
ルールの階層化について
ルールセットに優先順位はありません。 代わりに、リポジトリ内の同じブランチまたはタグが複数のルールセットの対象になっている場合、これらの各ルールセットのルールが集約されます。 集約されたルールセット間で同じルールに異なる定義がある場合、最も制限の厳しいバージョンのルールが適用されます。 ルールセットは、互いに階層化するだけでなく、同じブランチまたはタグを対象とする保護ルールとの階層化もできます。
たとえば、octo-org/octo-repo リポジトリの my-feature ブランチについて、次のような状況を考えてみましょう。
- リポジトリの管理者が、
my-featureブランチを対象とするルールセットを設定しました。 このルールセットは、署名されたコミットと、マージ前に pull request に対する 3 回のレビューを必須とします。 my-featureブランチには既存のブランチ保護ルールがあり、直線状のコミット履歴と、マージ前に pull request に対する 2 回のレビューが必須となっています。
それぞれのソースのルールが集約され、すべてのルールが適用されます。 同じルールの複数の異なるバージョンが存在する場合、ルールの最も制限の厳しいバージョンが適用されます。 そのため、my-feature ブランチでは、署名されたコミットと直線状のコミット履歴が必須であり、このブランチをターゲットとする pull request にはマージ前にレビューが 3 回必要です。