코드 소유자 정보

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

코드 소유자 정보

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

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

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

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

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

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

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

ODEOWNERS 파일에 잘못된 구문이 포함된 줄이 있으면 해당 줄은 건너뜁니다. 리포지토리에서 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. Without an owner, changes
# to `apps/github` can be made with the approval of any user who has
# write access to the repository.
/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 및 분기 보호

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

*.js     @global-owner1 @global-owner2

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

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

추가 참고 자료

• "새 파일 만들기"
• "개인 리포지토리에 협력자 초대"
• "조직 리포지토리에 대한 개인 액세스 권한 관리"
• "조직 리포지토리에 대한 팀 액세스 관리"
• "끌어오기 요청 검토 확인"