보호 규칙은 브랜치에 대한 접근을 제어하고, 하나의 브랜치에 여러 규칙이 적용될 때 어떻게 동작할지 결정합니다. 보호 규칙을 통해 리포지터리 브랜치에 적합한 보안 조치를 적용할 수 있습니다. 이러한 규칙은 다음을 다룹니다.

• 권한 수준, 우선순위, 규칙 충돌
• 여러 일치 규칙에 걸친 강제 푸시 권한
• Code Owner 승인
• 그룹과 프로젝트 사이의 보호 설정

규칙 동작#

브랜치가 여러 보호 규칙과 일치하면 다음과 같이 동작합니다.

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

푸시 및 머지 권한#

브랜치가 보호되면 기본적으로 다음 제한이 적용됩니다.

1. Developer 권한을 가진 사용자는 그룹에 프로젝트를 만들 수 있지만, 처음에는 기본 브랜치에 푸시하지 못할 수 있습니다.
2. Git 명령으로는 누구도 보호된 브랜치를 삭제할 수 없습니다. 다만 최소 Maintainer 권한을 가진 사용자는 UI 또는 API에서 보호된 브랜치를 삭제할 수 있습니다.

이러한 권한을 구성할 때 특정 권한을 선택하면 해당 권한과 그보다 상위인 모든 권한의 사용자에게 접근이 허용됩니다. 예를 들면 다음과 같습니다.

• Maintainers를 선택하면 Maintainer 및 Owner 권한을 가진 사용자에게 접근이 허용됩니다.
• Developers + Maintainers를 선택하면 Developer, Maintainer, Owner 권한을 가진 사용자에게 접근이 허용됩니다.

이 동작은 상위 권한을 가진 사용자가 하위 권한 사용자에게 허용된 접근을 그대로 유지하도록 보장합니다.

강제 푸시 권한#

강제 푸시 권한도 가장 허용적인 규칙이 적용되는 방식을 따릅니다. 예를 들어 와일드카드가 포함된 다음 규칙을 살펴봅니다.

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

• Allow force push: 세 설정 중 Yes가 가장 허용적이므로 브랜치 동작을 결정합니다. 이 브랜치가 더 엄격한 권한을 가진 v1.x와 v*에도 일치하지만, 이 브랜치에 푸시할 수 있는 사용자는 강제 푸시도 할 수 있습니다.

코드 소유자 승인#

푸시 및 머지 권한이나 강제 푸시 권한과 달리 코드 소유자 승인은 가장 제한적인 규칙을 따릅니다. 브랜치가 여러 규칙으로 보호되는 경우 적용 가능한 규칙 중 하나라도 Required approval from code owners가 활성화되어 있으면 코드 소유자 승인이 필요합니다. 자세한 내용은 코드 소유자 승인 요구를 참고합니다.

예를 들어 다음 규칙을 살펴봅니다.

v1.x라는 이름의 브랜치는 v1.x, v1.*, v* 세 가지 브랜치 이름 패턴에 모두 일치합니다. 규칙 중 하나(v1.x)가 코드 소유자 승인을 요구하므로, 이 브랜치로 향하는 모든 머지 리퀘스트는 머지하기 전에 Code Owner의 승인을 받아야 합니다.

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

브랜치 보호 규칙은 그룹과 프로젝트 양쪽에서 설정할 수 있습니다.

• 그룹 규칙은 그룹 내 모든 프로젝트에 적용되며 프로젝트 설정에서 수정할 수 없습니다.
• 프로젝트 규칙은 규칙을 설정한 프로젝트에만 적용됩니다.

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

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

프로젝트 설정에서 그룹 규칙을 편집하거나 제거할 수는 없지만, 같은 브랜치에 대해 프로젝트 규칙을 추가할 수는 있습니다. 이렇게 함께 평가하면 그룹 규칙만 있을 때보다 더 허용적인 동작이 될 수 있습니다.

예를 들면 다음과 같습니다.

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

여러 브랜치 규칙 예시#

다음 예시는 서로 다른 규칙이 브랜치 보호에 어떤 영향을 주는지 보여줍니다.

머지 허용#

정확한 브랜치 이름이 더 허용적인 와일드카드 패턴을 덮어쓰지 않는 예시입니다.

• release-v1.0 브랜치는 세 패턴 모두에 일치합니다. 가장 허용적인 규칙이 적용됩니다.
  • Allowed to merge: Developer + Maintainer가 머지할 수 있습니다(* 규칙 적용).

푸시 및 머지 허용#

여러 브랜치 규칙이 서로 다른 브랜치 이름에 적용되는 예시입니다.

• main 브랜치는 두 패턴(main과 m*)에 일치합니다. 가장 허용적인 규칙이 적용됩니다.
  • Allowed to merge: Developer + Maintainer가 머지할 수 있습니다(m* 규칙 적용).
  • Allowed to push and merge: Developer + Maintainer가 푸시할 수 있습니다(m* 규칙 적용).
• release-v1.0 브랜치는 한 패턴에 일치합니다.
  • Allowed to merge: 누구도 머지할 수 없습니다(r* 규칙 적용).
  • Allowed to push and merge: 누구도 푸시할 수 없습니다(r* 규칙 적용).

코드 소유자 요건#

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

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

엄격한 보호 적용#

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

이제 일치하는 모든 규칙이 No one만 푸시할 수 있도록 지정하므로 production 브랜치는 제한적인 푸시 권한을 갖습니다.

관련 주제#

• 보호된 브랜치
• 보호된 브랜치 API
• 브랜치 규칙
• Code Owners