Skip to main content

코드 소유자 정보

CODEOWNERS 파일을 사용하여 리포지토리의 코드를 담당하는 개인 또는 팀을 정의할 수 있습니다.

누가 이 기능을 사용할 수 있는 있나요?

People with write permissions for the repository can create or edit the CODEOWNERS file and be listed as code owners. People with admin or owner permissions can require that pull requests have to be approved by code owners before they can be merged.

조직의 경우 GitHub Free 및 GitHub Free을(를) 사용하여 퍼블릭 리포지토리에서 코드 소유자를 정의할 수 있으며, 퍼블릭 및 프라이빗 리포지토리에서는 GitHub Pro, GitHub Team, GitHub Enterprise Cloud 및 GitHub Enterprise Server을(를) 사용하여 코드 소유자를 정의할 수 있습니다. 자세한 내용은 “GitHub의 플랜”를 참조하세요.

코드 소유자로 선택한 사용자는 리포지토리에 대한 쓰기 권한이 있어야 합니다. 코드 소유자가 팀인 경우 해당 팀이 표시되어야 하며, 팀의 모든 개별 멤버에게 직접, 조직 멤버 자격을 통해 또는 다른 팀 멤버 자격을 통해 쓰기 권한이 있더라도 팀에 쓰기 권한이 있어야 합니다.

코드 소유자 정보

코드 소유자는 자신이 소유한 코드를 수정하는 끌어오기 요청을 다른 사용자가 열 때 자동으로 검토 요청을 받습니다. 코드 소유자에게 초안 끌어오기 요청을 검토하도록 자동으로 요청되지는 않습니다. 초안 끌어오기 요청에 대한 자세한 내용은 "끌어오기 요청 정보"을 참조하세요. 초안 끌어오기 요청을 검토 준비로 표시하면 코드 소유자가 자동으로 알림을 받게 됩니다. 끌어오기 요청을 초안으로 변환하는 경우 이미 알림을 구독한 사용자는 자동으로 구독 취소되지 않습니다. 자세한 내용은 "끌어오기 요청의 스테이지 변경"을(를) 참조하세요.

관리자 또는 소유자 권한이 있는 사용자가 필요한 검토를 사용하도록 설정한 경우 작성자가 리포지토리에서 끌어오기 요청을 병합하기 전에 필요에 따라 코드 소유자의 승인을 요구할 수도 있습니다. 자세한 내용은 "보호된 분기 정보"을(를) 참조하세요.

파일에 코드 소유자가 있는 경우 끌어오기 요청을 열기 전에 코드 소유자가 누구인지 확인할 수 있습니다. 리포지토리에서 파일로 이동하고 에 커서를 올리면 코드 소유권 세부 정보가 포함된 도구 설명을 볼 수 있습니다.

파일의 머리글을 보여주는 스크린샷. 커서를 방패 아이콘 위로 올리면 이 아이콘에 "소유자 또는 팀이 소유함(CODEOWNERS 줄 번호)"이라는 도구 설명이 표시됩니다.

CODEOWNERS 파일 위치

CODEOWNERS 파일을 사용하려면 리포지토리의 .github/, 루트 또는 docs/ 디렉터리에서 코드 소유자를 추가하려는 분기에 CODEOWNERS(이)라는 새 파일을 만듭니다. CODEOWNERS파일이 해당 위치 중 한 곳 이상에 있는 경우 GitHub은(는) 해당 순서대로 파일을 검색하고 찾은 첫 번째 항목을 사용합니다.

각 CODEOWNERS 파일은 리포지토리의 단일 분기에 대한 코드 소유자를 할당합니다. 따라서 기본 분기의 코드베이스에는 @octo-org/codeowners-team, gh-pages 분기의 GitHub Pages 사이트에는 @octocat를 할당하는 등 분기마다 다른 코드 소유자를 할당할 수 있습니다.

코드 소유자가 검토 요청을 받으려면 CODEOWNERS 파일이 끌어오기 요청의 기본 분기에 있어야 합니다. 예를 들어 리포지토리의 gh-pages 분기에서 .js 파일의 코드 소유자로 @octocat를 할당하는 경우 @octocat는 헤드 분기와 gh-pages 간에 .js 파일에 대한 변경 내용이 포함된 끌어오기 요청이 열릴 때 검토 요청을 받게 됩니다.

CODEOWNERS 및 포크

검토 요청을 트리거기 위해 끌어오기 요청은 끌어오기 요청의 CODEOWNERS 기본 분기 버전을 사용합니다. 기본 분기란 끌어오기 요청이 병합될 경우 끌어오기 요청을 수정하는 분기입니다.

포크에서 끌어오기 요청을 만들고 기본 분기가 업스트림 리포지토리에 있는 경우, 끌어오기 요청은 업스트림 리포지토리의 해당 분기에서 CODEOWNERS 파일을 사용합니다. 기본 분기가 포크 내의 분기인 경우 끌어오기 요청은 포크에 있는 해당 분기의 CODEOWNERS파일을 사용하지만, 코드 소유자가 특히 write 액세스 권한이 있는 포크에 추가된 경우에만 검토 요청을 트리거합니다.

을(를) 커서로 가리켜 파일을 담당하는 사람을 보는 경우, 보고 있는 리포지토리의 분기에 대한 CODEOWNERS 파일 정보를 확인할 수 있습니다.

CODEOWNERS 파일 크기

CODEOWNERS 파일의 크기는 3MB 미만이어야 합니다. 이 한도를 초과하는 CODEOWNERS 파일은 로드되지 않으므로 코드 소유자 정보가 표시되지 않으며 적절한 코드 소유자에게 끌어오기 요청의 변경 내용을 검토하도록 요청되지 않습니다.

CODEOWNERS 파일의 크기를 줄이려면 와일드카드 패턴을 사용하여 여러 항목을 단일 항목으로 통합하는 것이 좋습니다.

CODEOWNERS 구문

경고: CODEOWNERS 파일에서는 적용되지 않는 gitignore 파일의 몇 가지 구문 규칙이 있습니다.__

  • 주석이 아닌 패턴으로 처리되도록 \를 사용하여 #으로 시작하는 패턴 이스케이프
  • !를 사용하여 패턴 부정
  • [ ]를 사용하여 문자 범위 정의

CODEOWNERS 파일은 gitignore 파일에서 사용되는 것과 동일한 규칙을 대부분 따르는 패턴을 사용합니다. 패턴 뒤에는 표준 @username 또는 @org/team-name 형식을 사용하는 GitHub 사용자 이름 또는 팀 이름이 하나 이상 옵니다. 팀 멤버에게 이미 액세스 권한이 있더라도 사용자와 팀에게 리포지토리에 대한 명시적 write 권한이 있어야 합니다.

패턴이 같은 두 개 이상의 코드 소유자 일치하려는 경우 모든 코드 소유자가 동일한 줄에 있어야 합니다. 코드 소유자 동일한 줄에 없는 경우 패턴은 오직 마지막으로 언급된 코드의 소유자와 일치합니다.

대부분의 경우 GitHub.com의 계정에 추가된 이메일 주소로 사용자를 참조할 수도 있습니다(예: user@example.com). 메일 주소를 사용하여 관리형 사용자 계정을(를) 참조할 수 없습니다. 관리형 사용자 계정에 대한 자세한 내용은 GitHub Enterprise Cloud documentation.

GitHub에서 대/소문자를 구분하는 파일 시스템을 사용하기 때문에 CODEOWNERS 경로는 대/소문자를 구분합니다. CODEOWNERS가 GitHub에서 평가되기 때문에 대/소문자를 구분하지 않는 시스템(예: macOS)에서도 CODEOWNERS 파일에서 대/소문자가 올바르게 지정되는 경로와 파일을 사용해야 합니다.

CODEOWNERS 파일에 잘못된 구문이 포함된 줄이 있으면 해당 줄은 건너뜁니다. GitHub.com의 리포지토리에서 CODEOWNERS 파일로 이동하면 하이라이트된 오류를 확인할 수 있습니다(있는 경우). 리포지토리 CODEOWNERS 파일의 오류 목록은 API를 통해서도 액세스할 수 있습니다. 자세한 내용은 "리포지토리에 대한 REST API 엔드포인트"을(를) 참조하세요.

CODEOWNERS 파일의 예

# This is a comment.
# Each line is a file pattern followed by one or more owners.

# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence,
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.
*       @global-owner1 @global-owner2

# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only @js-owner and not the global
# owner(s) will be requested for a review.
*.js    @js-owner #This is an inline comment.

# You can also use email addresses if you prefer. They'll be
# used to look up users just like we do for commit author
# emails.
*.go docs@example.com

# Teams can be specified as code owners as well. Teams should
# be identified in the format @org/team-name. Teams must have
# explicit write access to the repository. In this example,
# the octocats team in the octo-org organization owns all .txt files.
*.txt @octo-org/octocats

# In this example, @doctocat owns any files in the build/logs
# directory at the root of the repository and any of its
# subdirectories.
/build/logs/ @doctocat

# The `docs/*` pattern will match files like
# `docs/getting-started.md` but not further nested files like
# `docs/build-app/troubleshooting.md`.
docs/*  docs@example.com

# In this example, @octocat owns any file in an apps directory
# anywhere in your repository.
apps/ @octocat

# In this example, @doctocat owns any file in the `/docs`
# directory in the root of your repository and any of its
# subdirectories.
/docs/ @doctocat

# In this example, any change inside the `/scripts` directory
# will require approval from @doctocat or @octocat.
/scripts/ @doctocat @octocat

# In this example, @octocat owns any file in a `/logs` directory such as
# `/build/logs`, `/scripts/logs`, and `/deeply/nested/logs`. Any changes
# in a `/logs` directory will require approval from @octocat.
**/logs @octocat

# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as its owners are left empty.
/apps/ @octocat
/apps/github

# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as this subdirectory has its own owner @doctocat
/apps/ @octocat
/apps/github @doctocat

CODEOWNERS 및 분기 보호

리포지토리 소유자는 변경된 파일의 소유자가 변경된 코드를 검토하도록 분기 보호 규칙을 업데이트할 수 있습니다. 분기 보호 규칙을 편집하고 "코드 소유자의 검토 필요" 옵션을 사용하도록 설정합니다. 자세한 내용은 "보호된 분기 정보"을(를) 참조하세요.

참고: 코드 소유자의 검토가 필요한 경우 소유자 중 누구라도 승인하면 이 요구 사항을 충족할 수 있습니다. 예를 들어, CODEOWNERS 파일에 다음 줄이 포함되어 있다고 가정해 보겠습니다.

*.js     @global-owner1 @global-owner2

즉, JavaScript 파일에 대한 변경 내용은 @global-owner1 또는 @global-owner2 중 하나에 의해 승인될 수 있지만 _두 명 모두_의 승인이 필요하지는 않습니다.

무단 변경으로부터 리포지토리를 완전히 보호하려면 CODEOWNERS 파일 자체에 대한 소유자도 정의해야 합니다. 가장 안전한 방법은 리포지토리의 .github 디렉터리에 CODEOWNERS 파일을 정의하고 리포지토리 소유자를 CODEOWNERS 파일(/.github/CODEOWNERS @owner_username) 또는 전체 디렉터리(/.github/ @owner_username)의 소유자로 정의하는 것입니다.

분기 보호 규칙 또는 태그 보호 규칙 대신 규칙 집합을 만들 수 있습니다. 규칙 집합은 상태 같은 분기 및 태그 보호 규칙에 비해 몇 가지 장점이 있으며 관리자 액세스를 요구하지 않고도 검색 가능성이 향상됩니다. 여러 규칙 집합을 동시에 적용할 수도 있습니다. 자세한 내용은 "규칙 세트 정보"을(를) 참조하세요.

추가 참고 자료