코드 소유자

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed형, GitLab Dedicated

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

  • 소유자의 승인 필요: 보호된 브랜치를 코드 소유자와 결합하여 Merge Request이 보호된 브랜치로 Merge되기 전에 전문가가 승인하도록합니다.

  • 소유자 식별: 코드 소유자 이름은 소유하는 파일 및 디렉터리에 표시됩니다:

    UI에 표시된 코드 소유자

Merge Request의 승인 규칙(옵션 또는 필수 여부)과 결합하여 유연한 승인 워크플로우를 구축하세요:

  • 코드 소유자를 사용하여 품질 보증. 리포지터리의 특정 경로에 대한 도메인 전문 지식을 가진 사용자를 정의합니다.
  • 승인 규칙을 사용하여 리포지터리의 특정 파일 경로와 일치하지 않는 전문 분야를 정의합니다. 승인 규칙은 프론트엔드 개발자 또는 보안 팀과 같은 올바른 리뷰어 집합으로 Merge Request 생성자를 안내하는 데 도움이 됩니다.

예를 들어:

유형 이름 범위 코멘트
승인 규칙 UX 모든 파일 사용자 경험(UX)팀 구성원이 프로젝트에서 수행한 모든 변경 사항의 사용자 경험을 검토합니다.
승인 규칙 보안 모든 파일 보안 팀 구성원이 취약점을 보완하기 위해 모든 변경 사항을 검토합니다.
코드 소유자 승인 규칙 프론트엔드: 코드 스타일 *.css 파일 프론트엔드 엔지니어가 CSS 파일 변경 내용을 프로젝트 스타일 표준과 일치하는지 검토합니다.
코드 소유자 승인 규칙 백엔드: 코드 리뷰 *.rb 파일 백엔드 엔지니어가 루비 파일의 로직 및 코드 스타일을 검토합니다.
동영상 소개: Code Owners.

파일 또는 디렉터리의 코드 소유자 보기

파일 또는 디렉터리의 코드 소유자를 보려면 다음을 수행하세요:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 코드 > 리포지터리를 선택합니다.
  3. 코드 소유자를 보려는 파일 또는 디렉터리로 이동합니다.
  4. (선택 사항) 브랜치 또는 태그를 선택합니다.

GitLab은 페이지 상단에 코드 소유자를 표시합니다.

코드 소유자 설정

전제 조건:

  • 기본 브랜치로 푸시하거나 Merge Request을 생성할 수 있어야 합니다.
  1. 선호하는 위치에 CODEOWNERS 파일을 만듭니다(#codeowners-file).
  2. 코드 소유자 구문 참조에 따라 파일에 일부 규칙을 정의합니다. 일부 제안:
  3. 변경 사항을 커밋하고 GitLab에 푸시합니다.

CODEOWNERS 파일

CODEOWNERS 파일(확장명 없음)은 리포지터리의 특정 파일 및 디렉터리를 담당하는 사용자 또는 공유 그룹을 지정합니다.

각 리포지터리는 단일 CODEOWNERS 파일을 사용합니다. GitLab은 리포지터리에서 이러한 위치를 확인합니다. 순서대로 CODEOWNERS 파일을 찾습니다. 찾은 첫 번째 CODEOWNERS 파일을 사용하고 다른 모든 파일은 무시됩니다:

  1. 루트 디렉터리: ./CODEOWNERS.
  2. docs 디렉터리: ./docs/CODEOWNERS.
  3. .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

그룹 상속 및 자격 승인자

%%{init: { "fontFamily": "GitLab Sans" }}%% 그래픽 TD 에[상위 그룹 X] -->|소유| 비[프로젝트 A] 에 -->|포함| 씨[하위 그룹 Y] 씨 -->|소유| 디[프로젝트 B] 에-. 소유권 상속 .-> 디

이 예에서:

  • 상위 그룹 X(group-x)이 프로젝트 A를 소유합니다.
  • 상위 그룹 X에는 하위 그룹인 하위 그룹 Y(group-x/subgroup-y)가 포함됩니다.
  • 하위 그룹 Y가 프로젝트 B를 소유합니다.

자격이 있는 코드 소유자는:

  • 프로젝트 A: 그룹 X의 구성원만 해당합니다. 이유는 프로젝트 A가 하위 그룹 Y에 속하지 않기 때문입니다.
  • 프로젝트 B: 그룹 X와 그룹 Y의 구성원이 모두 해당됩니다.
상위 그룹의 프로젝트에 하위 그룹 초대

요청 가능 코드 소유자로 사용자 그룹 하위 그룹 Y를 프로젝트 A로 초대하여 구성원도요청을 제출할 수 있습니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% 그래픽 LR 에[상위 그룹 X] -->|소유| 비[프로젝트 A] 에 -->|또한 포함| 씨[하위 그룹 Y] 씨 -.->디{하위 그룹 Y를<br/>프로젝트 A에 초대하시겠습니까?} -.->|예| 이[하위 그룹 Y 구성원<br/>가능한 Elasticsearch추가] 디{하위 그룹 Y를<br/>프로젝트 A에 초대하시겠습니까?} -.->|아니요| 아[하위 그룹 Y 구성원<br /> 요청 제출 불가] 이 -.->|하위 그룹 Y구성원<br/>을 프로젝트 A에<br/>코드 소유자로 추가합니다| 아[결제 명령은 반드시<br/>필요함] -.-> 비 아 -.-> |하위 그룹 Y를 프로젝트 A에<br/>코드 소유자로 추가합니다| 제[승인은 선택 사항일 뿐] -.-> 비

요청 신청하는 경우 하위 그룹 Y를 프로젝트 A로 초대하지 않고 코드 소유자로 만들면 merge 요청의
스텁이 선택 사항이 됩니다.

부모 그룹에 하위 그룹 초대

호출 하위 그룹 Y를 프로젝트 A에 초대하는 것은 지원되지 않습니다. 하위 그룹 Y를 코드 소유자로 만들려면 이 그룹을 직접 프로젝트에 초대해야 합니다.

note
그룹으로 코드 소유자로 권한 부여에는 프로젝트에 대한 직접 멤버십(상속된 멤버십이 아니어야 함)이 필요합니다. 코드 소유자 그룹의 멤버는 부모 그룹으로부터 상속된 멤버십이 아니어야 하며, 승인은 상속된 멤버십을 갖는 그룹에 한해 선택 사항일 수밖에 없습니다.

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

파일 또는 디렉터리가 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

Merge Request 위젯에 나열된 각 코드 소유자는 라벨 아래에 표시됩니다. 다음 이미지는 그룹 및 문서 섹션을 보여줍니다.

Merge Request 위젯 - 섹션별 코드 소유자

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

섹션 내의 여러 파일 경로가 동일한 소유권을 공유하는 경우 섹션에 대한 기본 코드 소유자를 정의하세요. 그 섹션의 모든 경로는 이 기본 소유자를 상속받으며, 섹션 기본을 특정한 줄에서 재정의하지 않는 한 사용합니다.

특정 파일 경로에 대해 지정된 소유자가 없을 때 기본 소유자가 적용됩니다. 파일 경로 옆에 정의된 특정 소유자는 기본 소유자를 재정의합니다.

예: 

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

[데이터베이스] @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
문서/
README.md

^[Database] @database-team
model/db/
config/db/database-setup.md @docs-team

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

섹션 밖에서 기본 코드 소유자를 설정하면 항상 승인이 필요합니다. 이러한 항목은 섹션에 의해 재정의되지 않습니다. 섹션이없는 항목은 다른, 이름이없는 섹션이 있는 것처럼 다룹니다. 

# 모든 파일에 필요한 항목
* @general-approvers

[Documentation] @docs-team
문서/
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을 수정하는 Merge Request에는 @general-approvers, @docs-team, @database-team 그룹 각각에서 승인이 필요합니다.

이 동작을 섹션의 기본 소유자만 사용할 때 섹션 내의 특정 항목이 섹션 기본을 재정의할 때 나오는 동작과 비교하세요.

겹치는 이름을 가진 섹션

여러 섹션이 같은 이름을 가지면 결합됩니다. 또한 섹션 헤딩은 대소문자를 구분하지 않습니다. 예를 들어: 

[문서]
ee/docs/    @docs
docs/       @docs

[데이터베이스]
README.md  @database
model/db/   @database

[DOCUMENTATION]
README.md  @docs

이 코드는 Documentation 섹션 헤더 아래 세 개의 항목과 Database 아래 두 개의 항목을 결과로 남깁니다. Documentation 및 DOCUMENTATION 섹션에서 정의된 항목은 첫 번째 섹션의 대문자를 사용하여 결합됩니다.

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

코드 소유자 파일에서 선택적 섹션을 지정할 수 있습니다. 선택적 섹션을 사용하면 코드베이스의 여러 부분에 대한 책임 있는 당사자를 지정할 수 있지만 합의가 필요하지 않습니다. 이 방식은 자주 업데이트되지만 엄격한 검토가 필요하지 않은 프로젝트 부분에 대한 더 유연한 정책을 제공합니다.

전체 섹션을 선택적으로 처리하려면 섹션 이름 앞에 캐럿 ^ 문자를 붙입니다.

이 예에서 [Go] 섹션이 선택적입니다: 

[문서]
*.md @root

[Ruby]
*.rb @root

^[Go]
*.go @root

선택적 코드 소유자 섹션이 설명란에서 표시됩니다:

MR 위젯 - 선택적 코드 소유자 섹션

파일에서 섹션이 중복되고 하나는 선택적으로 표시되고 다른 하나는 그렇지 않은 경우 해당 섹션은 필수입니다.

CODEOWNERS 파일의 선택적 섹션은 Merge Request을 통해 제출되는 변경 사항에 대해서만 선택적으로 취급됩니다. 보호된 브랜치에 직접 제출하는 경우에는 선택적으로 표시된 섹션에 대한 코드 소유자 승인이 필요합니다.

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

Merge Request의 승인 영역에서 코드 소유자 섹션으로부터 다중 승인을 요청할 수 있습니다. 섹션 이름 뒤에 숫자 n을 괄호에 추가하여 예를 들어 [2] 또는 [3]을 추가하세요. 이는 이 섹션의 코드 소유자로부터 n개의 승인이 필요함을 의미합니다. n에 대한 유효한 항목은 ≥ 1의 정수입니다. [1]은 기본적으로 사용 가능합니다. n에 대한 잘못된 값은 1로 처리됩니다.

caution
Issue 384881이 이 설정의 동작을 변경하도록 제안합니다. 잘못된 값으로 인정하는 의도적인 행위는 하지 마십시오. 이로 인해 예기치 않은 동작을 일으킬 수 있습니다.

코드 소유자로부터 다중 승인을 필요로하는 경우:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 설정 > 리포지터리를 선택합니다.
  3. 보호된 브랜치를 확장합니다.
  4. 기본 브랜치 옆의 토글을 켜세요.
  5. CODEOWNERS 파일을 편집하여 [Documentation] 섹션에서 다중 승인을 요구하는 규칙을 추가합니다.

예를 들어, [Documentation] 섹션에 두 개의 승인이 필요하도록 지정하려면: 

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

[Ruby]
*.rb @dev-team

승인 영역에서 Documentation 코드 소유자 섹션은 두 개의 승인이 필요하다는 내용으로 표시됩니다:

Merge Request 위젯 - 다중 승인 코드 소유자 섹션

푸시 허용

푸시 허용을 받은 사용자는 자신의 변경 사항에 대한 Merge Request을 생성하거나 변경 사항을 직접 브랜치에 푸시할 수 있습니다. 사용자가 Merge Request 프로세스를 건너뛰면 보호된 브랜치 기능과 Merge Request에 내장된 코드 소유자 승인도 건너뛰어집니다.

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

푸시 허용 권한이없는 사용자의 모든 변경 사항은 반드시 Merge Request을 통해 라우팅되어야 합니다.

관련 토픽

문제 해결

코드 소유자를 다룰 때 다음과 같은 문제가 발생할 수 있습니다.

오류 처리에 대한 자세한 내용은 Code Owners 참조를 참조하십시오.

선택 사항으로 표시된 승인

코드 소유자 승인 규칙은 다음 중 하나라도 해당되면 선택 사항입니다:

승인 미표시

Merge Request이 생성될 때만 코드 소유자 승인 규칙이 업데이트됩니다. CODEOWNERS 파일을 업데이트하면, Merge Request을 닫고 새로 생성해야 합니다.

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

다음 중 하나라도 해당되면 사용자는 코드 소유자 Merge Request 승인 규칙에서 승인자로 표시되지 않을 수 있습니다:

  • 특정 사용자가 Merge Request을 승인하는 것을 방지하는 규칙이 있습니다. 프로젝트 Merge Request 승인 설정을 확인하세요.
  • 코드 소유자 그룹이 비공개로 설정되어 현재 사용자가 코드 소유자 그룹의 구성원이 아닐 때.
  • 현재 사용자가 내부 코드 소유자 그룹에 권한이 없는 외부 사용자일 때.

승인 규칙이 잘못되었음

다음과 같이 오류가 발생할 수 있습니다. 

승인 규칙이 잘못되었습니다.
GitLab은 Merge Request을 차단해제하기 위해이 규칙을 자동으로 승인했습니다.

이 문제는 승인 규칙이 프로젝트의 직접적인 구성원이 아닌 코드 소유자를 사용할 때 발생합니다.

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

코드 소유자 보기 시 사용자 또는 그룹이 표시되지 않음

설정된 규칙에 따라 디렉터리를 보면 코드 소유자가 의도한 대로 표시되지 않을 수 있지만, 디렉터리 아래 파일에는 올바르게 코드 소유자가 표시됩니다.

예: 

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

docs/ 디렉터리 아래의 모든 파일은 @tech-writer-team을 코드 소유자로 표시하지만 디렉터리 자체는 @dev-team을 표시합니다.

이 동작은 디렉터리를 보는 경우 발생하는데, 이는 구문 규칙이 디렉터리 자체를 포함하지 않고 디렉터리 아래의 모든 파일에 적용되기 때문입니다. 이를 해결하려면 CODEOWNERS 파일을 업데이트하여 디렉터리를 명시적으로 포함하고 디렉터리 아래의 모든 파일을 포함하도록 합니다. 예를 들어: 

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