Code Owners

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated

코드 소유자 기능을 사용하여 프로젝트 코드베이스의 특정 부분에 대한 전문 지식을 가진 사람을 정의하세요. 저장소의 파일 및 디렉토리의 소유자를 정의하여 다음을 수행할 수 있습니다:

소유자의 승인 요청. 보호된 브랜치와 코드 소유자를 결합하여 보호된 브랜치로 병합되기 전에 전문가의 승인을 요청합니다.
소유자 식별. 코드 소유자 이름은 소유하는 파일 및 디렉토리에 표시됩니다:

병합 요청 승인 규칙(선택 사항 또는 필수)과 코드 소유자를 결합하여 유연한 승인 워크플로우를 구축하세요:

코드 소유자를 사용하여 품질을 보장하세요. 저장소의 특정 경로에 도메인 전문 지식을 가진 사용자를 정의합니다.
승인 규칙을 사용하여 저장소의 특정 파일 경로와 일치하지 않는 전문 분야를 정의하세요. 승인 규칙은 프론트엔드 개발자 또는 보안 팀과 같은 올바른 리뷰어 그룹을 지정하는 데 도움이 됩니다.

예를 들어:

유형	이름	범위	설명
승인 규칙	사용자 경험(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

그룹 상속 및 자격

이 예에서:

Parent group X (group-x)이 Project A를 소유합니다.
Parent group X에는 하위 그룹 Subgroup Y가 포함되어 있습니다. (group-x/subgroup-y)
Subgroup Y가 Project B를 소유합니다.

자격이 있는 코드 소유자는 다음과 같습니다:

Project A: 그룹 X의 멤버만 가능합니다. 왜냐하면 Project A는 Subgroup Y에 속해 있지 않기 때문입니다.
Project B: 그룹 X와 Subgroup Y의 멤버 모두 가능합니다.

상위 그룹에서 프로젝트에 하위 그룹 초대

Subgroup Y를 Project A에 초대하여 그들의 멤버도 자격이 있는 코드 소유자가 되도록 할 수 있습니다.

graph LR A[Parent group X] -->|owns| B[Project A] A -->|also contains| C[Subgroup Y] C -.->D{Subgroup Y를 Project A에 초대하시겠습니까?} -.->|yes| E[Subgroup Y의 멤버는 승인을 제출할 수 있음] D{Subgroup Y를 Project A에 초대하시겠습니까?} -.->|no| F[Subgroup Y의 멤버는 승인을 제출할 수 없음] E -.->|Project A에 Subgroup Y 를 코드 소유자로 추가| I[승인이 필요할 수 있음] -.-> B F -.-> |Project A에 Subgroup Y 를 코드 소유자로 추가| J[승인은 선택 사항일 수 있음] -.-> B

만약 Subgroup Y를 Project A에 초대하지 않고 코드 소유자로 만든다면, 그들의 병합 요청 승인은 선택 사항이 됩니다.

상위 그룹에 하위 그룹 초대

Subgroup Y를 Project A의 상위 그룹에 초대하는 것은 지원되지 않습니다. Subgroup Y를 코드 소유자로 설정하려면, 이 그룹을 직접 프로젝트에 초대해야 합니다.

참고: 승인이 필요한 경우, 코드 소유자로 사용되는 그룹은 프로젝트에 직접 멤버십 (상속된 멤버십이 아님)을 가져야 합니다. 상속된 멤버십은 승인이 선택 사항일 수 있습니다. 또한, 코드 소유자 그룹의 멤버들은 부모 그룹에서 멤버십을 상속받는 것이 아니라 직접 멤버여야 합니다.

보다 구체적으로 정의된 파일 또는 디렉터리에 대한 더 구체적인 소유자 정의

CODEOWNERS 파일의 파일이나 디렉터리가 여러 항목과 일치하는 경우, 파일이나 디렉터리와 일치하는 마지막 패턴의 사용자가 사용됩니다. 이렇게 하면 합리적인 방법으로 항목을 정렬하면, 보다 구체적으로 정의된 파일이나 디렉터리에 대한 보다 구체적인 소유자를 정의할 수 있습니다.

예를 들어, 다음 CODEOWNERS 파일에서:

# 이 줄은 파일 terms.md와 일치합니다.
*.md @doc-team

# 이 줄도 파일 terms.md와 일치합니다.
terms.md @legal-team

terms.md의 코드 소유자는 @legal-team입니다.

섹션을 사용하면, 각 섹션의 파일이나 디렉터리와 일치하는 마지막 패턴이 사용됩니다. 섹션을 사용하는 CODEOWNERS 파일의 예:

[README 소유자]
README.md @user1 @user2
internal/README.md @user4

[README 다른 소유자]
README.md @user3

루트 디렉터리의 README.md의 코드 소유자는 @user1, @user2, 및 @user3입니다. internal/README.md의 코드 소유자는 @user4 및 @user3입니다.

섹션 당 하나의 CODEOWNERS 패턴만 파일 경로에 일치합니다.

섹션에 코드 소유자를 넣어 조직화하기

이름이 지정된 섹션에 코드 소유자를 넣어 조직화할 수 있습니다.

공유 디렉터리에 대해 섹션을 사용하여 여러 팀이 리뷰어가 될 수 있도록 설정할 수 있습니다.

CODEOWNERS 파일에 섹션을 추가하려면 대괄호 안에 섹션 이름을 입력한 후, 파일이나 디렉터리 및 사용자, 그룹 또는 하위 그룹을 입력하세요:

[README 소유자]
README.md @user1 @user2
internal/README.md @user2

병합 요청 위젯의 각 코드 소유자는 레이블 아래에 나열됩니다. 다음 이미지는 그룹 및 문서 섹션을 보여줍니다:

섹션에 대한 기본 소유자 설정

GitLab 15.11에서 소개됨 (기본적으로 비활성화된 기능 플래그 codeowners_default_owners 포함)
GitLab 15.11에서 일반적으로 사용 가능. 기능 플래그 codeowners_default_owners 제거됨.

섹션 내에서 여러 파일 경로가 동일한 소유권을 공유하는 경우, 섹션에 대한 기본 코드 소유자를 정의하세요. 특정 파일 경로에 대해 특별한 소유자가 지정되지 않은 경우, 모든 경로가 이 기본 값을 상속받습니다.

기본 소유자는 파일 경로에 대해 특별한 소유자가 지정되지 않은 경우에 적용됩니다. 파일 경로 옆에 특정 소유자가 정의되어 있는 경우, 기본 소유자를 재정의합니다.

예를 들어:

[문서] @docs-team
docs/
README.md

[데이터베이스] @database-team @agarcia
model/db/
config/db/database-setup.md @docs-team

이 예에서:

@docs-team은 문서 섹션의 모든 항목을 소유합니다.
@database-team과 @agarcia는 데이터베이스 섹션의 모든 항목을 소유하지만 config/db/database-setup.md는 @docs-team으로 재정의됩니다.

이 동작은 일반 항목 및 섹션을 함께 사용할 때와 다르게, 섹션의 항목이 섹션이 없는 항목을 덮어쓰지 않습니다.

#### 기본 소유자 및 선택적 섹션 함께 사용하기

기본 소유자 구문을 [선택적 섹션](#make-a-code-owners-section-optional) 및 필수 승인과 함께 결합하려면 기본 소유자를 끝에 배치하십시오.

```plaintext
[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 파일의 선택적 섹션은 어떤지원에서만 선택적으로 취급됩니다. 변경 내용이 보호된 브랜치에 직접 제출되는 경우에도 코드 소유자의 승인이 필요합니다.

코드 소유자로부터 다중 승인 필요

도입됨 in GitLab 15.9.

병합 요청의 승인 영역에서 코드 소유자 섹션에 대해 여러 승인을 요구할 수 있습니다. 섹션 이름 뒤에 번호 n을 괄호로 묶어 추가하면 n개의 코드 소유자 승인이 필요합니다. n에 대한 유효한 항목은 ≥ 1인 정수입니다. [1]은 기본값이기 때문에 선택 사항입니다. n에 대한 무효한 값은 1로 처리됩니다.

경고: Issue 384881에서 이 설정의 동작에 대한 변경이 제안됩니다. 의도적으로 유효하지 않은 값을 설정하지 마십시오. 미래에 유효한 값이 될 수 있으며 예기치 않은 동작을 유발할 수 있습니다.

코드 소유자로부터 여러 승인이 필요한 경우:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > 저장소를 선택합니다.
보호된 브랜치를 확장합니다.
기본 브랜치 옆에있는 토글을 켭니다.
CODEOWNERS 파일을 편집하여 [Documentation] 섹션에 대한 두 개의 승인 규칙을 추가합니다.

예를 들어, [Documentation] 섹션에 두 개의 승인이 필요한 경우:

[Documentation][2]
*.md @tech-writer-team

[Ruby]
*.rb @dev-team

스시베 확인 영역의 Documentation 코드 소유자 섹션에서 두 개의 승인이 필요함이 나타납니다:

```

푸시 허용

푸시 허용(Allowed to push) 권한을 가진 사용자는 변경 사항에 대한 병합 요청을 만들거나 변경 사항을 직접 브랜치에 푸시할 수 있습니다. 사용자가 병합 요청 프로세스를 건너뛸 경우, 보호된 브랜치 기능과 병합 요청에 포함된 코드 주인 승인도 함께 건너뜁니다.

이 권한은 주로 내부 사용자 및 릴리스 도구와 관련된 계정에 부여됩니다.

푸시 허용(Allowed to push) 권한이 없는 사용자로부터의 모든 변경 사항은 반드시 병합 요청을 통해 라우팅되어야 합니다.

문제 해결

코드 주인을 다루면서 다음과 같은 문제가 발생할 수 있습니다.

코드 주인 기능이 오류를 처리하는 방법에 대한 자세한 정보는 코드 주인 참조를 참조하세요.

선택적으로 표시되는 승인

코드 주인 승인 규칙이 선택적인 경우, 다음 조건 중 하나 이상이 참인 경우 선택적입니다:

사용자 또는 그룹이 프로젝트의 구성원이 아닌 경우 코드 주인은 상위 그룹에서 구성원을 상속할 수 없습니다.
보호된 브랜치에서 코드 주인 승인이 설정되지 않은 경우.
해당 섹션이 선택적으로 표시됐음.
충돌로 인해 적격한 코드 주인이 다른 병합 요청 승인 설정과 충돌하여 병합 요청 승인을 승인할 수 없는 경우.

승인이 표시되지 않음

코드 주인 승인 규칙은 병합 요청을 생성할 때만 업데이트됩니다. CODEOWNERS 파일을 업데이트하면, 병합 요청을 닫고 새로운 요청을 생성하세요.

사용자가 가능한 승인자로 표시되지 않음

특정 사용자가 병합 요청을 승인할 수 없도록 하는 규칙이 있는 경우 사용자가 코드 주인 병합 요청 승인 규칙에 승인자로 표시되지 않을 수 있습니다. 다음 조건 중 하나 이상이 참인 경우 사용자가 승인자로 표시되지 않을 수 있습니다:

프로젝트 병합 요청 승인 설정을 확인하여 특정 사용자가 병합 요청을 승인할 수 없도록 하는 규칙이 있는지 확인하세요.
코드 주인 그룹의 가시성이 비공개이며, 현재 사용자가 코드 주인 그룹의 구성원이 아닌 경우.
현재 사용자가 내부 코드 주인 그룹에 대한 권한이 없는 외부 사용자인 경우.

승인 규칙이 잘못됨

다음과 같은 오류가 표시될 수 있습니다:

승인 규칙이 잘못됨.
GitLab은 이 규칙을 자동으로 승인하여 병합 요청을 차단 해제합니다.

이 문제는 병합 요청에 승인 규칙을 사용하는 코드 주인이 해당 프로젝트의 직접적인 구성원이 아닌 경우 발생합니다.

해결 방법은 해당 그룹이나 사용자가 프로젝트에 초대되었는지 확인하는 것입니다.

코드 주인 또는 그룹이 디렉토리의 코드 주인으로 표시되지 않음

구성된 규칙에 따라 디렉토리를 보거나 디렉토리의 사용자 또는 그룹을 특정시했음에도 불구하고, 디렉토리를 볼 때 의도한 사용자 또는 그룹이 표시되지 않을 수 있습니다. 하지만, 해당 디렉토리 아래의 파일에 대한 코드 주인은 올바르게 표시됩니다.

예를 들어:

* @dev-team
docs/ @tech-writer-team

docs/ 디렉토리 아래의 모든 파일이 @tech-writer-team을 코드 주인으로 표시하지만, 디렉토리 자체는 @dev-team이 표시됩니다.

이러한 동작은 디렉토리를 볼 때 발생하며, 이는 디렉토리 자체가 아닌 디렉토리 아래의 모든 파일에 구문 규칙이 적용되기 때문입니다. 해결책은 CODEOWNERS 파일을 업데이트하여 디렉토리와 함께 디렉토리 아래의 모든 파일을 명시적으로 포함하는 것입니다. 예를 들어:

* @dev-team
docs @tech-writer-team
docs/ @tech-writer-team

Code Owners

파일이나 디렉토리의 코드 소유자 보기

코드 소유자 설정

`CODEOWNERS` 파일

사용자 또는 그룹 이름 변경 시

그룹을 코드 소유자로 추가

그룹 상속 및 자격

상위 그룹에서 프로젝트에 하위 그룹 초대

상위 그룹에 하위 그룹 초대

보다 구체적으로 정의된 파일 또는 디렉터리에 대한 더 구체적인 소유자 정의

섹션에 코드 소유자를 넣어 조직화하기

섹션에 대한 기본 소유자 설정

일반 항목 및 섹션 함께 사용하기

이름 중복 섹션

코드 소유자 섹션을 선택적으로 만들기

코드 소유자로부터 다중 승인 필요

푸시 허용

관련 주제

문제 해결

선택적으로 표시되는 승인

승인이 표시되지 않음

사용자가 가능한 승인자로 표시되지 않음

승인 규칙이 잘못됨

코드 주인 또는 그룹이 디렉토리의 코드 주인으로 표시되지 않음

도움말

기능 사용 가능성과 제품 평가판

도움받기

Code Owners

파일이나 디렉토리의 코드 소유자 보기

코드 소유자 설정

CODEOWNERS 파일

사용자 또는 그룹 이름 변경 시

그룹을 코드 소유자로 추가

그룹 상속 및 자격

상위 그룹에서 프로젝트에 하위 그룹 초대

상위 그룹에 하위 그룹 초대

보다 구체적으로 정의된 파일 또는 디렉터리에 대한 더 구체적인 소유자 정의

섹션에 코드 소유자를 넣어 조직화하기

섹션에 대한 기본 소유자 설정

일반 항목 및 섹션 함께 사용하기

이름 중복 섹션

코드 소유자 섹션을 선택적으로 만들기

코드 소유자로부터 다중 승인 필요

푸시 허용

관련 주제

문제 해결

선택적으로 표시되는 승인

승인이 표시되지 않음

사용자가 가능한 승인자로 표시되지 않음

승인 규칙이 잘못됨

코드 주인 또는 그룹이 디렉토리의 코드 주인으로 표시되지 않음

도움말

기능 사용 가능성과 제품 평가판

도움받기

`CODEOWNERS` 파일