管理者あるいはオーナー権限を持つ人は、リポジトリ中に CODEOWNERS ファイルをセットアップできます。
The people you choose as code owners must have read permissions for the repository. 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.
コードオーナーについて
コードオーナーは、他者が所有するコードを変更するプルリクエストをオープンすると、自動的にレビューをリクエストされます。 コードオーナーはドラフトのプルリクエストのレビューを自動的にリクエストされません。 ドラフトのプルリクエストに関する詳しい情� �については「プルリクエストについて」を参照してく� さい。 コードオーナーはドラフトのプルリクエストのレビューを自動的にリクエストされません。 プルリクエストをドラフトに変換する� �合、通知を既にサブスクライブしているユーザは自動的にサブスクライブ解除されません。 詳しい情� �については、「プルリクエストのステージを変更する」を参照してく� さい。
管理者あるいはオーナー権限を持つ誰かがレビュー必� �を有効化した� �合、作者がリポジトリ中でプルリクエストをマージできるための条件としてコードオーナーからの承認を必� �とすることもできます。 詳しい情� �については保護されたブランチについてを参照してく� さい。
ファイルにコードオーナーがいる� �合、プルリクエストをオープンする前にコードオーナーを確認できます。 リポジトリで、ファイルを参照して にカーソルを合わせることができます。
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. You can also refer to a user by an email address that has been added to their account on your GitHub Enterprise Server instance, for example user@example.com.
CODEOWNERS paths are case sensitive, because GitHub uses a case sensitive file system. Since CODEOWNERS are evaluated by GitHub, even systems that are case insensitive (for example, macOS) must use paths and files that are cased correctly in the CODEOWNERS file.
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, any change inside the `/scripts` directory
# will require approval from @doctocat or @octocat.
/scripts/ @doctocat @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
構文の例外
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. 詳しい情� �については、「保護されたブランチについて」を参照してく� さい。