코드 소유자
코드 소유자 기능을 사용하여 프로젝트의 코드베이스의 특정 부분에 대한 전문 지식을 가진 사람을 정의하세요.
저장소에서 파일 및 디렉토리의 소유자를 정의하여:
- 소유자가 변경 사항을 승인하도록 요구합니다. 보호된 브랜치와 코드 소유자를 결합하여 전문가가 보호된 브랜치로 병합하기 전에 병합 요청을 승인하도록 요구합니다.
-
소유자를 식별합니다. 코드 소유자 이름은 자신이 소유한 파일 및 디렉토리에 표시됩니다:
코드 소유자를 병합 요청 승인 규칙 (선택적 또는 필수)에 결합하여 유연한 승인 워크플로우를 구축하세요:
- 코드 소유자를 사용하여 품질을 보장합니다. 저장소의 특정 경로에 대한 도메인 전문 지식을 가진 사용자를 정의합니다.
- 승인 규칙을 사용하여 저장소의 특정 파일 경로와 일치하지 않는 전문 분야를 정의합니다. 승인 규칙은 병합 요청 작성자를 올바른 검토자 집합, 즉 프론트엔드 개발자 또는 보안 팀으로 유도하는 데 도움을 줍니다.
예를 들어:
타입 | 이름 | 범위 | 주석 |
---|---|---|---|
승인 규칙 | UX | 모든 파일 | 사용자 경험(UX) 팀원이 프로젝트에서 수행된 모든 변경 사항의 사용자 경험을 검토합니다. |
승인 규칙 | 보안 | 모든 파일 | 보안 팀원이 모든 변경 사항을 취약성에 대해 검토합니다. |
코드 소유자 승인 규칙 | 프론트엔드: 코드 스타일 |
*.css 파일 |
프론트엔드 엔지니어가 프로젝트 스타일 표준을 준수하는지 CSS 파일 변경 사항을 검토합니다. |
코드 소유자 승인 규칙 | 백엔드: 코드 검토 |
*.rb 파일 |
백엔드 엔지니어가 Ruby 파일의 로직 및 코드 스타일을 검토합니다. |
파일 또는 디렉토리의 코드 소유자 보기
파일 또는 디렉토리의 코드 소유자를 보려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 코드 > 저장소를 선택합니다.
- 코드 소유자를 보고 싶은 파일 또는 디렉토리로 이동합니다.
- 선택 사항. 브랜치 또는 태그를 선택합니다.
GitLab은 페이지 상단에 코드 소유자를 표시합니다.
코드 소유자 설정
전제 조건:
- 기본 브랜치에 푸시할 수 있거나 병합 요청을 생성할 수 있어야 합니다.
-
선호하는 위치에
CODEOWNERS
파일을 생성합니다. -
코드 소유자 구문 참조를 따라 파일에 몇 가지 규칙을 정의합니다.
몇 가지 제안:- 모든 적격 승인자 승인 규칙 구성.
- 보호된 브랜치에서 코드 소유자 승인 요청 요구.
- 변경 사항을 커밋하고 GitLab에 푸시합니다.
CODEOWNERS
파일
CODEOWNERS
파일(확장자 없음)은 저장소의 특정 파일 및 디렉토리에 대한 책임이 있는 사용자 또는 공유 그룹을 지정합니다.
각 저장소는 단일 CODEOWNERS
파일을 사용합니다. GitLab은 다음 순서로 저장소에서 이러한 위치를 확인합니다. 처음 발견된 CODEOWNERS
파일이 사용되며 나머지는 무시됩니다:
- 루트 디렉토리:
./CODEOWNERS
. -
docs
디렉토리:./docs/CODEOWNERS
. -
.gitlab
디렉토리:./.gitlab/CODEOWNERS
.
자세한 정보는 코드 소유자 구문 및 오류 처리를 참조하세요.
사용자가 또는 그룹 이름을 변경할 때
사용자 또는 그룹이 이름을 변경하면, CODEOWNERS
는 새로운 이름으로 자동 업데이트되지 않습니다.
새로운 이름을 입력하려면 파일을 편집해야 합니다.
SAML SSO를 사용하는 조직은 사용자 이름을 설정할 수 있습니다. 사용자가 사용자 이름을 변경할 수 없도록 하기 위해서입니다.
그룹을 코드 소유자로 추가하기
그룹 또는 하위 그룹의 구성원을 코드 소유자로 설정하려면:
CODEOWNERS
파일에서 다음 패턴 중 하나에 따라 텍스트를 입력하세요:
# 파일의 코드 소유자로 모든 그룹 구성원
file.md @group-x
# 파일의 코드 소유자로 모든 하위 그룹 구성원
file.md @group-x/subgroup-y
# 파일의 코드 소유자로 모든 그룹 및 하위 그룹 구성원
file.md @group-x @group-x/subgroup-y
그룹 상속 및 자격
이 예에서:
-
상위 그룹 X (
group-x
)는 프로젝트 A를 소유합니다. -
상위 그룹 X는 또한 하위 그룹인 하위 그룹 Y를 포함합니다. (
group-x/subgroup-y
) - 하위 그룹 Y는 프로젝트 B를 소유합니다.
자격이 있는 코드 소유자는 다음과 같습니다:
- 프로젝트 A: 하위 그룹 Y에 속하지 않기 때문에 그룹 X의 구성원만.
- 프로젝트 B: 그룹 X와 하위 그룹 Y 모두의 구성원.
하위 그룹을 상위 그룹 프로젝트에 초대하기
하위 그룹 Y를 프로젝트 A에 초대할 수 있습니다. 그래서 그들의 구성원도 코드 소유자가 됩니다.
하위 그룹 Y를 프로젝트 A에 초대하지 않고 코드 소유자로 만든 경우, 그들의 병합 요청 승인은 선택 사항이 됩니다.
하위 그룹을 상위 그룹에 초대하기
프로젝트 A의 상위 그룹에 하위 그룹 Y를 초대하는 것은 지원되지 않습니다. 하위 그룹 Y를 코드 소유자로 설정하려면, 이 그룹을 프로젝트에 직접 초대해야 합니다.
참고: 승인이 필수로 설정되기 위해서는, 코드 소유자로 설정된 그룹은 프로젝트에 대한 직접 구성원이어야 합니다. 승인은 자격이 있는 구성원만 필요한 경우에만 선택 사항일 수 있습니다. 코드 소유자 그룹의 구성원 역시 직접 구성원이 되어야 하며, 모든 상위 그룹으로부터 구성원을 상속받아서는 안 됩니다.
더 구체적으로 정의된 파일 또는 디렉토리에 대해 더 구체적인 소유자를 정의하십시오
파일 또는 디렉토리가 CODEOWNERS
파일의 여러 항목과 일치할 경우,
파일 또는 디렉토리와 일치하는 마지막 패턴의 사용자가 사용됩니다.
이것은 항목을 합리적인 방식으로 정렬할 때 보다 구체적으로 정의된 파일이나 디렉토리에 대해 보다 구체적인 소유자를 정의할 수 있게 해줍니다.
예를 들어, 다음 CODEOWNERS
파일에서:
# 이 행은 terms.md 파일과 일치합니다
*.md @doc-team
# 이 행도 terms.md 파일과 일치합니다
terms.md @legal-team
terms.md
의 코드 소유자는 @legal-team
입니다.
섹션에 따라 코드 소유자를 정리하십시오
Code Owners 파일에서, _섹션_은 파일의 명명된 영역으로, 별도로 분석되고 항상 시행됩니다.
섹션을 정의하기 전까지 GitLab은 전체 코드 소유자 파일을 단일 섹션으로 취급합니다. 더 많은 섹션을 추가하면
GitLab이 코드 소유자 파일을 평가하는 방법이 변경됩니다:
- GitLab은 섹션이 없는 항목과, 첫 번째 섹션 헤더 이전에 정의된 규칙을 이름이 없는 다른 섹션처럼 취급합니다.
- 각 섹션은 그 규칙을 별도로 시행합니다.
- 각 섹션에 대해 파일 경로와 일치하는 CODEOWNERS 패턴은 하나만 일치합니다.
- 섹션 내에서는 GitLab이 각 섹션에 대해 파일 또는 디렉토리와 일치하는 마지막 패턴을 사용합니다.
예를 들어, 섹션을 사용하는 CODEOWNERS
파일에서 README
파일의 소유권을 살펴보면:
* @admin
[README Owners]
README.md @user1 @user2
internal/README.md @user4
[README other owners]
README.md @user3
-
루트 디렉토리의
README.md
에 대한 코드 소유자는 다음과 같습니다:- 이름이 없는 섹션에서의
@admin
. -
[README Owners]
에서의@user1
과@user2
. -
[README other owners]
에서의@user3
.
- 이름이 없는 섹션에서의
-
internal/README.md
의 코드 소유자는 다음과 같습니다:- 이름이 없는 섹션에서의
@admin
. -
[README Owners]
의 마지막 항목에서의@user4
. -
[README other owners]
에서의@user3
. (이 이름이 있는 섹션의 두 행은 이 파일 이름과 일치하지만, 섹션 내에서는 마지막 행만 유지됩니다.)
- 이름이 없는 섹션에서의
CODEOWNERS
파일에 섹션을 추가하려면, 대괄호로 섹션 이름을 입력한 다음, 파일이나 디렉토리 및 사용자, 그룹 또는 서브그룹을 입력하십시오:
[README Owners]
README.md @user1 @user2
internal/README.md @user2
병합 요청 위젯의 각 코드 소유자는 레이블 아래에 나열됩니다.
다음 이미지는 Default, Frontend, 및 Technical Writing 섹션을 보여줍니다:
섹션에 대한 기본 소유자 설정하기
- GitLab 15.11에서 도입됨 플래그와 함께
codeowners_default_owners
라는 이름으로. 기본적으로 비활성화됨.- GitLab 15.11에서 일반 제공. 기능 플래그
codeowners_default_owners
가 제거됨.
섹션 내에서 여러 파일 경로가 동일한 소유권을 공유하는 경우, 해당 섹션의 기본 코드 소유자를 정의하십시오.
해당 섹션의 모든 경로는 이 기본 값을 상속받으며, 특정 행에서 섹션의 기본 값을 오버라이드할 수 있습니다.
기본 소유자는 파일 경로에 대해 특정 소유자가 지정되지 않은 경우 적용됩니다.
파일 경로 옆에 정의된 특정 소유자는 기본 소유자를 오버라이드합니다.
예를 들어:
[Documentation] @docs-team
docs/
README.md
[Database] @database-team @agarcia
model/db/
config/db/database-setup.md @docs-team
이 예시에서:
-
@docs-team
은Documentation
섹션의 모든 항목을 소유합니다. -
@database-team
및@agarcia
는Database
섹션의 모든 항목을 소유하지만,config/db/database-setup.md
는@docs-team
으로 오버라이드됩니다.
이 동작을 정규 항목과 섹션을 함께 사용하는 것과 비교하십시오, 섹션 내 항목이 섹션 없는 항목을 오버라이드하지 않을 때의 경우입니다.
기본 소유자 및 선택적 섹션 함께 사용하기
기본 소유자의 구문과 선택적 섹션 및 필수 승인 요구 사항을 결합하려면 기본 소유자를 끝에 배치하세요:
[Documentation][2] @docs-team
docs/
README.md
^[Database] @database-team
model/db/
config/db/database-setup.md @docs-team
일반 항목 및 섹션 함께 사용하기
경로에 대한 기본 코드 소유자를 섹션 밖에 설정하면, 그들의 승인이 항상 필요합니다.
이러한 항목은 섹션에 의해 덮어쓰이지 않습니다.
섹션이 없는 항목은 다른 이름 없는 섹션인 것처럼 처리됩니다:
# 모든 파일에 필요
* @general-approvers
[Documentation] @docs-team
docs/
README.md
*.txt
[Database] @database-team
model/db/
config/db/database-setup.md @docs-team
이 예제에서는:
-
@general-approvers
는 어디서나 모든 항목을 소유하며, 덮어쓰기 없이 적용됩니다. -
@docs-team
은Documentation
섹션의 모든 항목을 소유합니다. -
@database-team
은Database
섹션의 모든 항목을 소유하지만config/db/database-setup.md
는@docs-team
에 할당된 덮어쓰기가 있습니다. -
model/db/CHANGELOG.txt
를 수정하는 병합 요청은 세 개의 승인이 필요합니다:@general-approvers
,@docs-team
, 및@database-team
그룹 각각의 한 건.
이 동작을 섹션에 대한 기본 소유자만 사용할 때와 비교하세요, 특정 섹션의 항목이 섹션 기본값을 덮어씌웁니다.
같은 이름의 섹션
동일한 이름의 섹션이 여러 개 있을 경우, 이들은 결합됩니다. 또한, 섹션 제목은 대소문자를 구분하지 않습니다. 예를 들어:
[Documentation]
ee/docs/ @docs
docs/ @docs
[Database]
README.md @database
model/db/ @database
[DOCUMENTATION]
README.md @docs
이 코드는 Documentation 섹션 헤더 아래에 세 개의 항목과 Database 아래에 두 개의 항목을 생성합니다. Documentation 및 DOCUMENTATION 섹션에 정의된 항목은 결합되어 첫 번째 섹션의 대소문자를 사용합니다.
코드 소유자 섹션을 선택적으로 만들기
코드 소유자 파일에서 선택적 섹션을 지정할 수 있습니다.
선택적 섹션을 사용하면 코드베이스의 다양한 부분에 대한 책임 당사를 지정하지만, 이들로부터 승인을 요구하지 않을 수 있습니다.
이 접근 방식은 자주 업데이트되지만 철저한 검토가 필요하지 않은 프로젝트의 일부에 대해 보다 느슨한 정책을 제공합니다.
전체 섹션을 선택적으로 처리하려면, 섹션 이름 앞에 캐럿 ^
문자를 추가하세요.
이 예에서 [Go]
섹션은 선택적입니다:
[Documentation]
*.md @root
[Ruby]
*.rb @root
^[Go]
*.go @root
선택적 코드 소유자 섹션은 병합 요청의 설명 아래에 표시됩니다:
파일에 섹션이 중복되고, 그 중 하나가 선택적으로 표시되고 다른 하나는 선택적이지 않은 경우, 해당 섹션은 필수입니다.
CODEOWNERS
파일의 선택적 섹션은 병합 요청을 통해 변경이 제출될 때만 선택적으로 처리됩니다.
보호된 브랜치에 직접적으로 변경을 제출할 경우, 섹션이 선택적으로 표시되더라도 코드 소유자의 승인이 여전히 필요합니다.
코드 소유자로부터 다수의 승인 요구하기
- 도입됨 GitLab 15.9.
병합 요청의 승인 영역에서 코드 소유자 섹션에 대해 여러 개의 승인을 요구할 수 있습니다.
섹션 이름 뒤에 숫자 n
을 대괄호로 추가하세요. 예를 들어, [2]
또는 [3]
.
이렇게 하면 이 섹션의 코드 소유자로부터 n
개의 승인을 요구합니다.
n
에 대한 유효한 항목은 정수 ≥ 1
입니다. [1]
은 기본값이므로 선택 사항입니다. n
에 대한 잘못된 값은 1
로 처리됩니다.
경고:
문제 384881는 이 설정의 동작에 대한 변경을 제안합니다.
의도적으로 잘못된 값을 설정하지 마세요.
이 값이 미래에 유효하게 되어 예기치 않은 동작을 초래할 수 있습니다.
코드 소유자로부터 다수의 승인을 요구하려면:
- 왼쪽 사이드바에서 Search or go to를 선택하여 프로젝트를 찾으세요.
- Settings > Repository를 선택하세요.
- Protected branches를 확장하세요.
- 기본 브랜치 옆에 있는 토글에서 Code owner approval를 활성화하세요.
- 다수의 승사를 위한 규칙을 추가하도록
CODEOWNERS
파일을 수정하세요.
예를 들어 [Documentation]
섹션에 대해 두 개의 승인이 필요하도록 하려면:
[Documentation][2]
*.md @tech-writer-team
[Ruby]
*.rb @dev-team
승인 영역의 Documentation
코드 소유자 섹션에 두 개의 승인이 필요하다고 표시됩니다:
푸시 허용
푸시 허용 사용자는 변경 사항에 대해 병합 요청을 생성하거나, 변경 사항을 직접 브랜치에 푸시할 수 있습니다. 사용자가 병합 요청 프로세스를 건너뛸 경우, 보호된 브랜치 기능과 병합 요청에 내장된 코드 소유자 승인은 건너뛰어집니다.
이 권한은 종종 자동화와 관련된 계정(내부 사용자) 및 릴리즈 도구에 부여됩니다.
푸시 허용 권한이 없는 사용자의 모든 변경 사항은 병합 요청을 통해 라우팅되어야 합니다.