보호 규칙과 권한

GitLab에서 보호 규칙이 보호 브랜치와 함께 작동하는 방식, 특히 복잡한 시나리오에서의 동작 방식.

보호 규칙은 브랜치에 대한 액세스를 제어하고 동일한 브랜치에 여러 규칙이 적용될 때 발생하는 일을 결정합니다. 리포지터리 브랜치에 대한 올바른 보안 조치를 구현하는 데 도움이 됩니다. 이 규칙은 다음을 다룹니다: 권한 수준, 우선순위 및 규칙 충돌. 여러 매칭 규칙에서의 강제 푸시 권한. 코드 소유자 승인. 그룹과 프로젝트 간의 보호 설정. 규칙 동작 # 브랜치가 여러 보호 규칙과 일치할 때 이러한 동작이 적용됩니다: 그룹 규칙은 그룹의 모든 프로젝트에 적용되며 프로젝트 설정에서 수정할 수 없습니다. 자세한 내용은 그룹과 프로젝트에 걸친 규칙 을 참조하세요. 브랜치가 여러 규칙과 일치하면 가장 허용적인 규칙이 적용됩니다. 그러나 코드 소유자 승인 은 가장 제한적인 규칙을 사용합니다. main 과 같은 정확한 브랜치 이름은 m* 와 같은 와일드카드 패턴을 재정의하지 않습니다. 푸시 및 병합 권한 # 히스토리 GitLab 16.0에서 GitLab 관리자도 허용 권한을 가져야 하도록 브랜치 푸시 권한이 변경 됨. 브랜치가 보호되면 기본 동작이 다음 제한을 적용합니다: 작업 가능한 사용자 브랜치 보호 Maintainer 또는 Owner 역할을 가진 사용자. 브랜치 푸시 허용 권한이 있는 모든 사용자. (1) 브랜치 강제 푸시 없음. 브랜치 삭제 없음. (2) Developer 역할을 가진 사용자는 그룹에 프로젝트를 만들 수 있지만 처음에 기본 브랜치 에 푸시하지 못할 수 있습니다. Git 명령을 사용하여 보호된 브랜치를 삭제할 수 없습니다. 그러나 Maintainer 이상의 역할을 가진 사용자는 UI 또는 API에서 보호된 브랜치를 삭제 할 수 있습니다. 이러한 권한을 구성할 때 역할을 선택하면 해당 역할과 모든 상위 역할의 사용자에게 액세스가 부여됩니다. 예: Maintainer 를 선택하면 Maintainer 및 Owner 역할의 사용자에게 액세스가 부여됩니다. Developer + Maintainer 를 선택하면 Developer, Maintainer 및 Owner 역할의 사용자에게 액세스가 부여됩니다. 이 동작은 더 높은 권한을 가진 사용자가 낮은 권한을 가진 사용자가 사용할 수 있는 액세스를 유지하도록 합니다. 강제 푸시 권한 # 강제 푸시 권한은 동일한 가장 허용적인 규칙 적용 논리를 따릅니다. 예를 들어 와일드카드 를 포함한 다음 규칙을 고려합니다: 브랜치 이름 패턴 강제 푸시 허용 v1.x Yes v1.* No v* No v1.x 라는 브랜치는 세 가지 브랜치 이름 패턴 v1.x , v1.* , v* 모두와 일치합니다. 가장 허용적인 옵션이 동작을 결정하므로 브랜치 v1.x 에 대한 권한은 다음과 같습니다: 강제 푸시 허용 : 세 가지 설정 중 Yes 가 가장 허용적이며 결과적으로 브랜치 동작을 제어합니다. 브랜치가 v1.x 및 v* (각각 더 엄격한 권한을 가짐)와도 일치했지만, 이 브랜치에 푸시할 수 있는 모든 사용자는 강제 푸시도 할 수 있습니다. 코드 소유자 승인 # 푸시 및 병합 권한, 강제 푸시 권한과 달리 코드 소유자