保護ルールと権限

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

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

ルールの動作

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

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

プッシュとマージの権限

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

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

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

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

この動作により、より高い権限を持つユーザーは、より低い権限を持つユーザーが利用できるアクセス権を保持できます。

強制プッシュ権限

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

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

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

コードオーナーの承認

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

たとえば、次のルールを検討してください:

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

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

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

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

あるブランチに一致するグループとプロジェクトの両方のルールが存在する場合:

• 一致するすべてのルールがまとめて評価されます。
• ほとんどの設定には、最も許可的なルールが適用されます。
• コードオーナーの承認の場合、最も制限の厳しいルールが適用されます。

プロジェクト設定からグループのルールを編集または削除することはできませんが、同じブランチに追加のプロジェクトルールを追加できます。例:

• 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
• ブランチルール
• GitLabコードオーナー