ルールセットについて

ルールセットについて

ルールセットは、organization 内の 1 つのリポジトリ、または複数のリポジトリに適用される規則の名前付きリストです。 1 つのリポジトリあたり最大 75 個のルールセット、organization 全体で最大 75 個のルールセットを設定できます。

ルールセットを作成するときに、特定のユーザーがルールセットの中のルールをバイパスすることを許可できます。 これは、リポジトリ管理者などの特定のロールを持つユーザー、または特定のチームや GitHub Apps にすることができます。 バイパスアクセス許可の付与の詳細については、「リポジトリのルールセットの作成」を参照してください。

GitHub Enterprise プランの organization では、organization 内の複数のリポジトリをターゲットにするように、Enterprise または organization レベルでルールセットを設定できます。 「組織内のリポジトリのルールセットを管理する」を参照してください。

ルールセットを使用して、リポジトリ内のブランチまたはタグをターゲットにしたり、リポジトリとリポジトリのフォーク ネットワーク全体へのプッシュをブロックしたりできます。

プッシュルールセットの委任されたバイパスを使用すると、プッシュ保護をバイパスできるユーザーと、ブロックされたプッシュを許可する必要があるユーザーを制御できます。

委任されたバイパスでは、リポジトリの投稿者は、制限された内容を含むコミットをプッシュする際に、「バイパス権限」を要求する必要があります。 要求は、指定されたレビュー担当者グループに送信されます。レビュー担当者は、プッシュ ルールをバイパスする要求を承認または拒否します。

プッシュ ルールをバイパスする要求が承認された場合、投稿者は制限された内容などコミットをプッシュできます。 要求が拒否された場合、投稿者は、再度プッシュする前に、制限された内容などのコミット (複数可) から内容を削除する必要があります。

委任されたバイパスを構成するには、組織の所有者またはリポジトリ管理者が最初に 「バイパス リスト」 を作成します。 バイパス リストには、チームやリポジトリ管理者など、プッシュ保護をバイパスする要求を監督する特定のロールとチームが含まれます。 詳細については、「組織内のリポジトリのルールセットを管理する」および「ルールセットについて」を参照してください。

ブランチとタグのルールセット

ルールセットを作成して、リポジトリ内の特定のブランチとタグをユーザーが操作する方法を制御できます。 どのユーザーが特定のブランチにコミットをプッシュできるか、コミットをどのようにフォーマットする必要があるか、どのユーザーがタグを削除または名前変更できるかといったことを制御できます。 たとえば、リポジトリの feature ブランチに対して、署名されたコミットを必須とし、リポジトリ管理者を除くすべてのユーザーの強制プッシュをブロックするルールセットを設定できます。

作成するルールセットごとに、リポジトリ内のどのブランチまたはタグ、または organization 内のどのリポジトリにルールセットを適用するかを指定します。 fnmatch 構文を使って、特定のブランチ、タグ、リポジトリを対象とするパターンを定義できます。 たとえば、パターン releases/**/* を使用すると、リポジトリ内の名前が文字列 releases/ で始まるすべてのブランチを対象とすることができます。 fnmatch 構文の詳細については、「リポジトリのルールセットの作成」を参照してください。

プッシュ ルールセット

プッシュ ルールセットを使用すると、ファイル拡張子、ファイル パスの長さ、ファイルとフォルダーのパス、ファイル サイズに基づいて、プライベート リポジトリまたは内部リポジトリとそのリポジトリのフォーク ネットワーク全体へのプッシュをブロックできます。

プッシュルールはリポジトリへのすべてのプッシュに適用されるため、ブランチのターゲット設定は必要ありません。

プッシュ ルールセットを使用すると、次のことができるようになります。

• ファイル パスを制限する: 指定したファイル パスに変更を含むコミットがプッシュされないようにします。

  これには fnmatch の構文を使用できます。 たとえば、test/demo/**/* を対象とする制限により、test/demo/ ディレクトリ内のファイルまたはフォルダーへのプッシュが禁止されます。 test/docs/pushrules.md を対象とした制限により、test/docs/ ディレクトリ内の pushrules.md ファイルへのプッシュが禁止されます。 詳しくは、「リポジトリのルールセットの作成」をご覧ください。

• ファイル パスの長さを制限する: 指定した文字制限を超えるファイル パスを含むコミットがプッシュされないようにします。

• ファイル拡張子を制限する: 指定したファイル拡張子を持つファイルを含むコミットがプッシュされないようにします。

• ファイル サイズを制限する: 指定したファイル サイズの制限を超えるコミットがプッシュされないようにします。

フォークされたリポジトリのプッシュ ルールセットについて

プッシュ ルールは、リポジトリのフォーク ネットワーク全体に適用され、リポジトリへのすべてのエントリ ポイントが確実に保護されます。 たとえば、プッシュルールセットが有効になっているリポジトリをフォークした場合、フォークされたリポジトリにも同じプッシュルールセットが適用されます。

フォークされたリポジトリの場合、プッシュ ルールのバイパス アクセス許可を持つユーザーは、ルート リポジトリのバイパス アクセス許可を持つユーザーだけです。

ルールセットと保護されたブランチについて

ルールセットは、リポジトリ内のブランチ保護規則と併用できます。 ルールセットで定義できるルールの多くは保護ルールに似ており、既存の保護ルールをオーバーライドせずにルールセットの使用を開始できます。

ルールセットには、ブランチ保護規則に比べて次の利点があります。

• 保護規則とは異なり、複数のルールセットを同時に適用できるため、誰かがそのブランチを操作するときに、リポジトリ内のブランチを対象とするすべての規則が確実に評価されることが保証されます。 「ルールの階層化について」を参照してください。
• ルールセットには状態があるため、ルールセットを削除しなくても、リポジトリでどのルールセットをアクティブにするかを簡単に管理できます。
• リポジトリへの読み取りアクセス権を持つユーザーは、リポジトリのアクティブなルールセットを表示できます。 これは、開発者がルールに抵触した理由を理解できること、または監査担当者がリポジトリへの管理者アクセス権を必要とせずに、リポジトリのセキュリティ制約を確認できることを意味します。
• コミット メッセージや作成者のメール アドレスなど、リポジトリに入力するコミットのメタデータを制御する追加のルールを作成できます。 「ルールセットで使用できるルール」を参照してください。

ルールセットの適用ステータスの使用

ルールセットの作成または編集中に、適用ステータスを使用してルールセットの適用方法を構成できます。

ルールセットには、次の適用ステータスのいずれかを選択できます。

• アクティブ: ルールセットは作成時に適用されます。
• 評価: ルールセットは適用されませんが、[Rule Insights] ページでルールに違反するアクションと違反しないアクションを監視できます。
• 無効: ルールセットは、適用または評価されません。

「評価」モードを使用することは、ルールセットを適用せずにテストするための優れたオプションです。 「ルールの分析情報」ページを使用して、そのコントリビューションがルールに違反したかどうかを確認できます。 詳しくは、「リポジトリのルールセットの管理」をご覧ください。

ルールの階層化について

ルールセットに優先順位はありません。 代わりに、リポジトリ内の同じブランチまたはタグが複数のルールセットの対象になっている場合、これらの各ルールセットのルールが集約されます。 集約されたルールセット間で同じルールに異なる定義がある場合、最も制限の厳しいバージョンのルールが適用されます。 ルールセットは、互いに階層化するだけでなく、同じブランチまたはタグを対象とする保護ルールとの階層化もできます。

たとえば、octo-org/octo-repo リポジトリの my-feature ブランチについて、次のような状況を考えてみましょう。

• リポジトリの管理者が、my-feature ブランチを対象とするルールセットを設定しました。 このルールセットは、署名されたコミットと、マージ前に pull request に対する 3 回のレビューを必須とします。
• 既存の my-feature ブランチのブランチ保護規則では、コミット履歴を線形にし、pull request をマージする前に 2 回確認する必要があります。
• octo-org Organization の管理者も、octo-repo リポジトリの my-feature ブランチを対象とするルールセットを設定しています。 このルールセットは強制プッシュを禁止し、pull request をマージする前に 1 回のレビューを必須としています。

それぞれのソースのルールが集約され、すべてのルールが適用されます。 同じルールの複数の異なるバージョンが存在する場合、ルールの最も制限の厳しいバージョンが適用されます。 そのため、my-feature ブランチでは、署名済みコミットと直線状のコミット履歴が必須であり、強制プッシュは禁止され、このブランチをターゲットとする pull request はマージ前に 3 回のレビューが必須です。

次のステップ

次に、README を使って Enterprise のメンバーに重要な情報を伝える方法について学びます。 「Enterprise 向け README を作成する」をご覧ください。