• 파일 또는 디렉터리의 코드 소유자 보기
• 코드 소유자 설정
  • CODEOWNERS 파일
    • 사용자나 그룹 이름이 변경될 때
  • 그룹을 코드 소유자로 추가
    • 그룹 상속과 자격
      • 상위 그룹에서 프로젝트로 서브그룹 초대
      • 상위 그룹에서 하위 그룹을 초대하기
  • 보다 구체적으로 정의된 파일 또는 디렉터리를 위한 보다 구체적인 소유자 정의
  • 섹션에 코드 소유자를 구성하세요.
    • 섹션에 대한 기본 소유자 설정
    • 기본 소유자 및 선택 섹션을 함께 사용
    • 정규 항목 및 섹션을 함께 사용
    • 코드 소유자 섹션을 선택적으로 만들기
  • 코드 소유자로부터 다중 승인 필요
  • 푸시 권한이 허용된 사용자
• 관련 주제

코드 소유자

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

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

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

  

병합 요청에 코드 소유자를 결합하고 승인 규칙 (옵션 또는 필수)을 사용하여 유연한 승인 워크플로우를 구축하세요.

• 코드 소유자를 사용하여 품질을 보장하세요. 저장소의 특정 경로에 도메인 전문 지식을 가진 사용자를 정의합니다.
• 승인 규칙을 사용하여 저장소의 특정 파일 경로에 해당하지 않는 전문 지식 영역을 정의합니다. 승인 규칙은 프론트엔드 개발자나 보안 팀과 같은 올바른 리뷰어 그룹으로 병합 요청 생성자를 안내하는 데 도움이 됩니다.

예를 들어:

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

파일 또는 디렉터리의 코드 소유자를 보려면:

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

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

코드 소유자 설정

전제 조건:

• 기본 브랜치로 푸시하거나 병합 요청을 생성할 수 있어야 합니다.

1. 선호하는 위치에 CODEOWNERS 파일을 만듭니다.
2. 코드 소유자 구문 참조를 따라 파일에 규칙을 정의합니다. 몇 가지 제안:
   • All eligible approvers 승인 규칙 구성.
   • 보호된 브랜치에 코드 소유자 승인을 필요로 함.
3. 변경 사항을 커밋하고 GitLab에 푸시합니다.

CODEOWNERS 파일

CODEOWNERS 파일(확장자 없음)은 저장소의 특정 파일과 디렉터리를 책임 지는 사용자 또는 공유 그룹을 지정합니다.

각 저장소는 하나의 CODEOWNERS 파일을 사용합니다. GitLab은 저장소에서 이러한 위치를 확인합니다. 이 순서대로 처음 발견된 CODEOWNERS 파일을 사용하고 다른 파일은 무시합니다.

1. 루트 디렉터리에: ./CODEOWNERS.
2. 문서 디렉터리에: ./docs/CODEOWNERS.
3. .gitlab 디렉터리에: ./.gitlab/CODEOWNERS.

자세한 정보는 코드 소유자 구문 및 오류 처리를 참조하십시오.

사용자나 그룹 이름이 변경될 때

사용자나 그룹 이름이 변경되면 CODEOWNERS는 새 이름으로 자동으로 업데이트되지 않습니다. 새 이름을 입력하려면 파일을 편집해야 합니다.

SAML SSO를 사용하는 조직은 사용자가 자신의 사용자 이름을 변경할 수 없도록 하기 위해 SAML에서 사용자 이름 설정할 수 있습니다.

그룹을 코드 소유자로 추가

그룹 또는 서브그룹의 멤버를 코드 소유자로 설정하려면:

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: 그룹 X의 멤버만 사용 가능합니다. 왜냐하면 프로젝트 A는 서브그룹 Y에 속해 있지 않기 때문입니다.
• 프로젝트 B: 그룹 X 및 서브그룹 Y의 멤버 모두 사용 가능합니다.

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

서브그룹 Y를 프로젝트 A에 초대하여 그들의 멤버도 코드 소유자가 되도록합니다.

서브그룹 Y를 프로젝트 A에 초대하지 않고 코드 소유자로 만들면 승인이 옵션으로 설정됩니다.

상위 그룹에서 하위 그룹을 초대하기

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

참고: 코드 소유자로서의 그룹에서 승인이 필요한 경우, 코드 소유자로서 그룹은 프로젝트에 대한 직접 멤버십(상속되지 않는 멤버십이 아닌)을 가져야합니다. 그룹이 상속 멤버십을 하는 경우에만 승인이 선택 사항이 될 수 있습니다. 코드 소유자 그룹의 멤버들은 직접 멤버여야 하며, 어떠한 상위 그룹에서도 멤버십을 상속받아서는 안됩니다.

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

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

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

# This line would match the file terms.md
*.md @doc-team

# This line would also match the file terms.md
terms.md @legal-team

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

섹션에 코드 소유자를 구성하세요.

코드 소유자 파일에서 _섹션_은 파일의 이름이 별도로 분석되고 항상 강제됩니다. 섹션을 정의하기 전까지 GitLab은 코드 소유자 파일 전체를 단일 섹션으로 취급합니다. 더 많은 섹션을 추가하면 GitLab이 코드 소유자 파일을 평가하는 방법이 변경됩니다.

• GitLab은 섹션 헤더 전에 정의된 규칙을 포함하여섹션이 없는 항목을 다른 섹션처럼 취급합니다.
• 각 섹션은 그 자체로 규칙을 별도로 적용합니다.
• 각 섹션에서는 파일 경로에 대해 매칭되는_마지막_ 패턴을 사용합니다.

예를 들어, 섹션을 사용하는 CODEOWNERS 파일에서 README 파일의 소유권을 살펴봅시다:

* @admin

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

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

• 루트 디렉토리의 README.md에 대한 코드 소유자는 다음과 같습니다:
  • 비명시적인 섹션에서 @admin.
  • [README 소유자]에서 @user1 및 @user2.
  • [README의 다른 소유자]에서 @user3.
• internal/README.md의 코드 소유자는 다음과 같습니다:
  • 비명시적인 섹션에서 @admin.
  • [README 소유자]의 마지막 항목에서 @user4.
  • [README의 다른 소유자]에서@user3 (이 섹션의 두 줄 모두 이 파일의 이름과 일치하지만, 섹션의 마지막 줄만 유지됩니다.)

CODEOWNERS 파일에 섹션을 추가하려면, 파일이나 디렉터리와 사용자, 그룹 또는 하위 그룹을 대괄호 안에 섹션 이름으로 입력하십시오:

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

병합 요청 위젯의 각 코드 소유자는 레이블 아래에 나열됩니다. 다음 이미지는 기본(Default), 프론트엔드(Frontend) 및 기술 문서(Technical Writing) 섹션을 보여줍니다:

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

• 기능 속성이름이 codeowners_default_owners로 지정된 플래그와 함께 GitLab 15.11에 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• 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으로 재할당하는 오버라이드가 있습니다.

이 행동은 섹션 내의 특정 항목이 섹션 기본값을 오버라이드하면서 섹션이 없는 항목을 처리할 때 일반 항목 및 섹션을 함께 사용하는 것과 비교할 수 있습니다.

기본 소유자 및 선택 섹션을 함께 사용

기본 소유자의 구문을 선택적 섹션 및 필수 승인과 함께 사용하려면 기본 소유자를 끝에 배치하십시오:

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

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

정규 항목 및 섹션을 함께 사용

섹션 바깥에서 기본 코드 소유자를 지정하면 해당 항목의 승인이 항상 필요합니다. 이러한 항목은 섹션으로 오버라이드되지 않습니다. 섹션이 아닌 항목은 다른, 이름이 지정되지 않은 섹션처럼 처리됩니다:

# 모든 파일에 필요합니다.
* @general-approvers

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

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

이 예에서:

• @general-approvers은 항상 모든 항목을 소유합니다.
• @docs-team은 문서 섹션의 모든 항목을 소유합니다.
• @database-team은 데이터베이스 섹션의 모든 항목을 소유하며, config/db/database-setup.md는 이를 @docs-team으로 재할당하는 오버라이드가 있습니다.
• model/db/CHANGELOG.txt를 수정하는 병합 요청은 세 개의 승인이 필요합니다. @general-approvers, @docs-team, @database-team 그룹 각각에서 하나씩입니다.

이 행동은 섹션에 대한 기본 소유자 설정만 사용하는 것과 비교할 수 있습니다. 섹션의 특정 항목이 섹션 기본값을 오버라이드하면 섹션내에 특정 항목이 섹션 관련 기본값을 무시하는 행동입니다.

#### 중복 이름을 가진 섹션들

여러 섹션이 동일한 이름을 가지는 경우 이들은 결합됩니다.
또한 섹션 헤딩은 대소문자를 가리지 않습니다. 예를 들어:

```plaintext
[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은 이 설정의 동작에 대한 변경을 제안합니다. 의도적으로 잘못된 값으로 설정하지 마십시오. 이 값들은 나중에 유효해질 수 있고 예상치 못한 동작을 유발할 수 있습니다.

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

1. 좌측 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
2. 설정 > 저장소를 선택합니다.
3. 보호된 브랜치를 확장합니다.
4. 기본 브랜치 옆에 코드 소유자 승인 아래의 토글을 켭니다.
5. CODEOWNERS 파일을 편집하여 다중 승인을 위한 규칙을 추가합니다.

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

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

[Ruby]
*.rb @dev-team

승인 영역에서 Documentation 코드 소유자 섹션이 두 개의 승인이 필요하다는 것을 보여줍니다:

푸시 권한이 허용된 사용자

푸시 권한이 허용된 사용자는 자신의 변경 사항에 대해 병합 요청을 생성하거나 변경을 직접 브랜치에 푸시할 수 있습니다. 사용자가 병합 요청 프로세스를 거치지 않는다면, 보호된 브랜치 기능과 병합 요청에 내장된 코드 소유자 승인도 건너뜁니다.

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

푸시 권한이 허용되지 않은 사용자의 모든 변경 사항은 병합 요청을 통해 라우팅되어야 합니다.

관련 주제

• 구문 참조
• 개발 가이드라인 ```