보호 규칙은 브랜치에 대한 액세스를 제어하고 동일한 브랜치에 여러 규칙이 적용될 때 발생하는 일을 결정합니다. 리포지터리 브랜치에 대한 올바른 보안 조치를 구현하는 데 도움이 됩니다. 이 규칙은 다음을 다룹니다:

• 권한 수준, 우선순위 및 규칙 충돌.
• 여러 매칭 규칙에서의 강제 푸시 권한.
• 코드 소유자 승인.
• 그룹과 프로젝트 간의 보호 설정.

규칙 동작#

브랜치가 여러 보호 규칙과 일치할 때 이러한 동작이 적용됩니다:

• 그룹 규칙은 그룹의 모든 프로젝트에 적용되며 프로젝트 설정에서 수정할 수 없습니다. 자세한 내용은 그룹과 프로젝트에 걸친 규칙을 참조하세요.
• 브랜치가 여러 규칙과 일치하면 가장 허용적인 규칙이 적용됩니다. 그러나 코드 소유자 승인은 가장 제한적인 규칙을 사용합니다.
• main과 같은 정확한 브랜치 이름은 m*와 같은 와일드카드 패턴을 재정의하지 않습니다.

푸시 및 병합 권한#

브랜치가 보호되면 기본 동작이 다음 제한을 적용합니다:

1. Developer 역할을 가진 사용자는 그룹에 프로젝트를 만들 수 있지만 처음에 기본 브랜치에 푸시하지 못할 수 있습니다.
2. Git 명령을 사용하여 보호된 브랜치를 삭제할 수 없습니다. 그러나 Maintainer 이상의 역할을 가진 사용자는 UI 또는 API에서 보호된 브랜치를 삭제할 수 있습니다.

이러한 권한을 구성할 때 역할을 선택하면 해당 역할과 모든 상위 역할의 사용자에게 액세스가 부여됩니다. 예:

• Maintainer를 선택하면 Maintainer 및 Owner 역할의 사용자에게 액세스가 부여됩니다.
• Developer + Maintainer를 선택하면 Developer, Maintainer 및 Owner 역할의 사용자에게 액세스가 부여됩니다.

이 동작은 더 높은 권한을 가진 사용자가 낮은 권한을 가진 사용자가 사용할 수 있는 액세스를 유지하도록 합니다.

강제 푸시 권한#

강제 푸시 권한은 동일한 가장 허용적인 규칙 적용 논리를 따릅니다. 예를 들어 와일드카드를 포함한 다음 규칙을 고려합니다:

v1.x라는 브랜치는 세 가지 브랜치 이름 패턴 v1.x, v1.*, v* 모두와 일치합니다. 가장 허용적인 옵션이 동작을 결정하므로 브랜치 v1.x에 대한 권한은 다음과 같습니다:

• 강제 푸시 허용: 세 가지 설정 중 Yes가 가장 허용적이며 결과적으로 브랜치 동작을 제어합니다. 브랜치가 v1.x 및 v*(각각 더 엄격한 권한을 가짐)와도 일치했지만, 이 브랜치에 푸시할 수 있는 모든 사용자는 강제 푸시도 할 수 있습니다.

코드 소유자 승인#

푸시 및 병합 권한, 강제 푸시 권한과 달리 코드 소유자 승인은 가장 제한적인 규칙을 사용합니다. 브랜치가 여러 규칙으로 보호되는 경우 적용 가능한 규칙 중 하나라도 코드 소유자의 승인 필요가 활성화되어 있으면 코드 소유자 승인이 필요합니다. 자세한 내용은 코드 소유자 승인 필요를 참조하세요.

예를 들어 다음 규칙을 고려합니다:

v1.x라는 브랜치는 세 가지 브랜치 이름 패턴 v1.x, v1.*, v* 모두와 일치합니다. 적어도 하나의 규칙(v1.x)이 코드 소유자 승인을 필요로 하므로 이 브랜치의 모든 머지 리퀘스트는 병합되기 전에 코드 소유자의 승인이 필요합니다.

그룹과 프로젝트에 걸친 규칙#

브랜치 보호 규칙은 그룹과 프로젝트 모두에 설정할 수 있습니다:

• 그룹 규칙은 그룹의 모든 프로젝트에 적용되며 프로젝트 설정에서 수정할 수 없습니다.
• 프로젝트 규칙은 해당 규칙이 설정된 프로젝트에만 적용됩니다.

그룹 규칙과 프로젝트 규칙이 모두 브랜치와 일치하는 경우 GitLab은 일치하는 모든 규칙을 함께 평가합니다:

• 대부분의 설정에서 가장 허용적인 규칙이 적용됩니다.
• 코드 소유자 승인의 경우 가장 제한적인 규칙이 적용됩니다.

프로젝트 설정에서 그룹 규칙을 편집하거나 제거할 수 없지만 동일한 브랜치에 대한 프로젝트 규칙을 추가할 수 있습니다. 결합된 평가는 그룹 규칙 단독보다 더 허용적인 동작을 초래할 수 있습니다.

예:

• main에 대한 그룹 규칙이 강제 푸시를 허용하지 않습니다.
• 프로젝트 Maintainer가 강제 푸시를 허용하는 main에 대한 프로젝트 규칙을 추가합니다.
• 두 규칙이 함께 평가됩니다. 가장 허용적인 규칙이 적용되므로 해당 프로젝트의 main 브랜치에서 강제 푸시가 허용됩니다.

여러 브랜치 규칙 예시#

다음 예시는 다양한 규칙이 브랜치 보호에 어떤 영향을 미치는지 보여줍니다.

병합 허용#

정확한 브랜치 이름이 더 허용적인 와일드카드 패턴을 재정의하지 않는 방법의 예시입니다.

• 브랜치 release-v1.0은 세 가지 패턴 모두와 일치합니다. 가장 허용적인 규칙이 적용됩니다:
  • 병합 허용: Developer + Maintainer가 병합 가능(규칙 *에서).

푸시 및 병합 허용#

여러 브랜치 규칙이 다양한 브랜치 이름에 적용되는 방법의 예시입니다.

• 브랜치 main은 두 가지 패턴(main 및 m*)과 일치합니다. 가장 허용적인 규칙이 적용됩니다:
  • 병합 허용: Developer + Maintainer가 병합 가능(규칙 m*에서).
  • 푸시 및 병합 허용: Developer + Maintainer가 푸시 가능(규칙 m*에서).
• 브랜치 release-v1.0은 한 가지 패턴과 일치합니다:
  • 병합 허용: 아무도 병합 불가(규칙 r*에서).
  • 푸시 및 병합 허용: 아무도 푸시 불가(규칙 r*에서).

코드 소유자 요건#

코드 소유자 승인은 다른 브랜치 보호 설정과 다르게 작동합니다. 여러 규칙이 일치하면 가장 허용적인 규칙 대신 가장 제한적인 규칙이 적용됩니다.

• 브랜치 production은 세 가지 패턴 모두와 일치합니다. 가장 제한적인 규칙이 적용됩니다:
  • 코드 소유자 승인: 필요(규칙 production 및 p*에서).
• 브랜치 product-v1.0은 두 가지 패턴(prod* 및 p*)과 일치합니다. 가장 제한적인 규칙이 적용됩니다:
  • 코드 소유자 승인: 필요(규칙 p*에서).

엄격한 보호 보장#

더 허용적인 패턴으로 재정의될 수 없는 엄격한 보호를 보장하려면 모든 일치하는 패턴을 동일한 제한적 설정으로 구성합니다.

이제 모든 일치하는 규칙이 아무도 푸시할 수 없다고 지정하므로 브랜치 production에 제한적인 푸시 권한이 있습니다.

관련 주제#

• 보호된 브랜치
• 보호된 브랜치 API
• 브랜치 규칙
• 코드 소유자