保護ルールと権限

保護ルールはブランチへのアクセスを制御し、複数のルールが同じブランチに適用される場合に何が起こるかを決定します。これらは、リポジトリのブランチに対して適切なセキュリティ対策を実施するのに役立ちます。これらのルールは以下を対象とします:

• 権限レベル、優先順位、およびルール競合。
• 複数のマッチングルールにわたる強制プッシュ権限。
• コードオーナーの承認。
• グループとプロジェクト間の保護設定。

ルール動作

ブランチが複数の保護ルールに一致する場合、これらの動作が適用されます:

• グループルールはグループ内のすべてのプロジェクトに適用され、プロジェクトの設定から変更することはできません。詳細については、rules across groups and projectsを参照してください。
• ブランチが複数のルールに一致する場合、最も緩やかなルールが適用されます。ただし、コードオーナーの承認は最も制限の厳しいルールを使用します。
• mainのような正確なブランチ名は、m*のようなワイルドカードパターンをオーバーライドしません。

プッシュとマージの権限

ブランチが保護されている場合、デフォルトの動作ではこれらの制限が適用されます:

1. デベロッパーロールを持つユーザーは、グループ内にプロジェクトを作成できますが、最初はデフォルトブランチへのプッシュが許可されない場合があります。
2. 保護ブランチをGitコマンドを使用して削除することはできませんが、少なくともメンテナーロールを持つユーザーは、保護ブランチを削除することができます。UIまたはAPIから削除できます。

これらの権限を設定すると、ロールを選択することで、そのロールとそれよりも上位のすべてのロールを持つユーザーにアクセス権が付与されます。例:

• メンテナーを選択すると、メンテナーロールとオーナーロールを持つユーザーにアクセス権が付与されます。
• デベロッパー + メンテナーを選択すると、デベロッパー、メンテナー、およびオーナーの各ロールを持つユーザーにアクセス権が付与されます。

この動作により、上位の権限を持つユーザーが下位の権限を持つユーザーに利用可能なアクセスを維持することが保証されます。

強制プッシュの権限

強制プッシュ権限にも、最も緩やかなルールが適用されるという同じロジックが適用されます。たとえば、ワイルドカードを含む次のルールを考えてみましょう。

v1.xという名前のブランチは、v1.x、v1.*、v*の3つのブランチ名パターンすべてに一致します。動作が最も寛容なオプションにより決定されるため、ブランチv1.xの結果の権限は次のようになります。

• 強制プッシュを許可する: 3つの設定のうちYesが最も寛容であるため、ブランチの動作を制御します。ブランチがv1.xおよびv*（それぞれより厳格な権限を持つ）にも一致した場合でも、このブランチにプッシュできるユーザーは強制プッシュも実行できます。

コードオーナー承認

プッシュおよびマージの権限、強制プッシュの権限とは異なり、コードオーナーの承認には最も厳格なルールが適用されます。ブランチが複数のルールで保護されている場合、該当するルールのいずれかでコードオーナーの承認が必要が有効になっている場合、コードオーナーの承認が必要になります。詳細については、コードオーナーの承認を要求するを参照してください。

たとえば、次のルールを検討します:

v1.xという名前のブランチは、v1.x、v1.*、v*の3つのブランチ名パターンすべてに一致します。少なくとも1つのルール（v1.x）がコードオーナーの承認を要求するため、このブランチへのすべてのマージリクエストは、コードオーナーによる承認がなければマージできません。

グループとプロジェクトにまたがるルール

ブランチ保護ルールは、グループとプロジェクトの両方で設定できます:

• グループルールはグループ内のすべてのプロジェクトに適用され、プロジェクトの設定から変更することはできません。
• プロジェクトルールは、設定されているプロジェクトにのみ適用されます。

グループルールとプロジェクトルールの両方がブランチに一致する場合、GitLabはすべての一致するルールをまとめて評価します:

• ほとんどの設定では、最も緩やかなルールが適用されます。
• コードオーナーの承認の場合、最も制限の厳しいルールが適用されます。

プロジェクトの設定からグループルールを編集または削除することはできませんが、同じブランチのプロジェクトルールを追加することはできます。組み合わせた評価は、グループルール単独よりも緩やかな動作になる可能性があります。

例:

• mainのグループルールは強制プッシュを許可しません。
• プロジェクトのメンテナーが、mainに対する強制プッシュを許可するプロジェクトルールを追加します。
• 両方のルールがまとめて評価されます。最も寛容なルールが適用されるため、そのプロジェクトのmainブランチでは強制プッシュが許可されます。

複数のブランチルール例

次の例は、異なるルールがブランチ保護にどのように影響するかを示しています。

マージを許可

正確なブランチ名が、より緩やかなワイルドカードパターンをオーバーライドしない例。

• ブランチrelease-v1.0はこれら3つのパターンすべてに一致します。最も緩やかなルールが適用されます:
  • マージを許可する: デベロッパー + メンテナーがマージできます（*ルールによる）。

プッシュとマージを許可

複数のブランチルールが異なるブランチ名にどのように適用されるかの例。

• ブランチmainは2つのパターン（mainおよびm*）に一致します。最も緩やかなルールが適用されます:
  • マージを許可する: デベロッパー + メンテナーがマージできます（m*ルールによる）。
  • プッシュとマージを許可する: デベロッパー + メンテナーがプッシュすることができます（m*ルールによる）。
• ブランチrelease-v1.0は1つのパターンに一致します:
  • マージを許可する: マージできるのはなしです（r*ルールによる）。
  • プッシュとマージを許可する: プッシュすることができるのはなしです（r*ルールによる）。

コードオーナーの要件

コードオーナーの承認は、他のブランチ保護設定とは異なる動作をします。複数のルールが一致する場合、最も緩やかなルールではなく、最も厳格なルールが適用されます。

• ブランチproductionはこれら3つのパターンすべてに一致します。最も厳格なルールが適用されます:
  • コードオーナーの承認: 必須（productionおよびp*ルールによる）。
• ブランチproduct-v1.0は2つのパターン（prod*およびp*）に一致します。最も厳格なルールが適用されます:
  • コードオーナーの承認: 必須（p*ルールによる）。

厳格な保護を確実にする

より緩やかなパターンによってオーバーライドできない厳格な保護を確実にするため、すべての一致するパターンを同じ厳格な設定で構成します。

現在、ブランチproductionは、すべてのマッチングルールがなしのプッシュ権限を指定しているため、制限されたプッシュ権限を持っています。

関連トピック

• 保護ブランチ
• 保護ブランチAPI
• ブランチルール
• コードオーナー