管理者あるいはオーナー権限を持つ人は、リポジトリ中に CODEOWNERS ファイルをセットアップできます。
コードオーナーに指定する人は、リポジトリへの書き込み権限を持っていなければなりません。 When the code owner is a team, that team must be visible and it must have write permissions, even if all the individual members of the team already have write permissions directly, through organization membership, or through another team membership.
コードオーナーについて
コードオーナーは、他者が所有するコードを変更するプルリクエストをオープンすると、自動的にレビューをリクエストされます。 コードオーナーはドラフトのプルリクエストのレビューを自動的にリクエストされません。 ドラフトのプルリクエストに関する詳しい情報については「プルリクエストについて」を参照してください。 コードオーナーはドラフトのプルリクエストのレビューを自動的にリクエストされません。 プルリクエストをドラフトに変換する場合、通知を既にサブスクライブしているユーザは自動的にサブスクライブ解除されません。 詳しい情報については、「プルリクエストのステージを変更する」を参照してください。
管理者あるいはオーナー権限を持つ誰かがレビュー必須を有効化した場合、作者がリポジトリ中でプルリクエストをマージできるための条件としてコードオーナーからの承認を必須とすることもできます。 詳しい情報については保護されたブランチについてを参照してください。
Team がコードレビューの割り当てを有効にしている場合、個々の承認は、保護されたブランチでのコードオーナーの承認要件を満たしません。 詳しい情報については、「Team のコードレビューの割り当てを管理する」を参照してください。
CODEOWNERSファイルの場所
CODEOWNERS ファイルを使うためには、コードオーナーを追加したいブランチで、リポジトリのルート、docs/、.github/ のいずれかのディレクトリに CODEOWNERS という新しいファイルを作成してください。
各CODEOWNERSファイルは、リポジトリ内の単一のブランチにコードオーナーを割り当てます。 したがって、デフォルトブランチのコードベースに @octo-org/codeowners-team、gh-pages ブランチの GitHub Pages サイトに @octocat など、ブランチごとに異なるコードオーナーを割り当てることができます。
コードオーナーがレビューのリクエストを受け取るためには、CODEOWNERS ファイルがプルリクエストの base ブランチになければなりません。 たとえばリポジトリ中のgh-pagesブランチの、.jsファイルのコードオーナーとして@octocatを割り当てたなら、.jsに変更を加えるプルリクエストがheadブランチとgh-pagesの間でオープンされると、@octocatはレビューのリクエストを受けることになります。
CODEOWNERSの構文
CODEOWNERS ファイルは、一部の例外を除いて、gitignore ファイルで使用されるルールのほとんどに従うパターンを使用します。 パターンの後には1つ以上のGitHubのユーザー名あるいはTeam名が続きます。これらの名前には標準の@usernameあるいは@org/team-nameフォーマットが使われます。 Users must have read access to the repository and teams must have explicit write access, even if the team's members already have access. たとえば user@example.com のような、ユーザの GitHub Enterprise Server アカウントに追加されたメールアドレスでユーザを参照することもできます。
CODEOWNERS ファイルのいずれかの行に無効な構文が含まれている場合、そのファイルは検出されず、レビューのリクエストには使用されません。
CODEOWNERS ファイルの例
# これはコメントです。
# 各行はファイルパターンの後に一人以上のオーナーが続きます。
# これらのオーナーは、リポジトリ中のすべてに対する
# デフォルトのオーナーになります。 後のマッチが優先されないかぎり、
# 誰かがプルリクエストをオープンすると、
# @global-owner1と@global-owner2にはレビューがリクエストされます。
* @global-owner1 @global-owner2
# 順序は重要です。最後にマッチしたパターンが最も
# 高い優先度を持ちます。 誰かがJSファイルだけを変更する
# プルリクエストをオープンすると、@js-ownerだけにレビューが
# リクエストされ、グローバルのオーナーにはリクエストされません。
*.js @js-owner
# メールアドレスの方が良ければ、そちらを使うこともできます。 それらは
# コミット作者のメールの場合と同じようにユーザの
# ルックアップに使われます。
*.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
# `docs/*`パターンは`docs/getting-started.md`のようなファイルには
# マッチしますが、それ以上にネストしている
# `docs/build-app/troubleshooting.md`のようなファイルにはマッチしません。
docs/* docs@example.com
# この例では、@octocatはリポジトリ中のあらゆる場所にある
# appsディレクトリ内のすべてのファイルのオーナーになります。
apps/ @octocat
# この例では、@doctocatはリポジトリのルートにある
# `/docs` ディレクトリとそのサブディレクトリにある
# ファイルを所有しています。
/docs/ @doctocat
# 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
構文の例外
gitignore ファイルには、CODEOWNERS ファイルでは動作しないいくつかの構文ルールがあります。
- Escaping a pattern starting with
#using\so it is treated as a pattern and not a comment !を使用してパターンを否定する[ ]を使用して文字範囲を定義する
CODEOWNERS and branch protection
Repository owners can add branch protection rules to ensure that changed code is reviewed by the owners of the changed files. 詳しい情報については、「保護されたブランチについて」を参照してください。
CODEOWNERS ファイルの例
# In this example, any change inside the `/apps` directory
# will require approval from @doctocat.
/apps/ @doctocat
# In this example, any change inside the `/apps` directory
# will require approval from @doctocat or @octocat.
/apps/ @doctocat @octocat
# In this example, any change inside the `/apps` directory
# will require approval from a member of the @example-org/content team.
# If a member of @example-org/content opens a pull request
# with a change inside the `/apps` directory, their approval is implicit.
# The team is still added as a reviewer but not a required reviewer.
# Anyone can approve the changes.
/apps/ @example-org/content-team