コードオーナーについて
CODEOWNERS ファイルを使い、リポジトリ中のコードに対して責任を負う個人あるいは Team を指定できます。
管理者あるいはオーナー権限を持つ人は、リポジトリ中に CODEOWNERS ファイルをセットアップできます。 コードオーナーに指定する人は、リポジトリへの書き込み権限を持っていなければなりません。
コードオーナーは、所有するコードを変更するプルリクエストを誰かがオープンすると、自動的にレビューを求められます。
管理者あるいはオーナー権限を持つ誰かがレビュー必須を有効化した場合、作者がリポジトリ中でプルリクエストをマージできるための条件としてコードオーナーからの承認を必須とすることもできます。 詳細は「プルリクエストの必須レビューを有効にする」を参照してください。
CODEOWNERSファイルの場所
CODEOWNERS ファイルを使うためには、コードオーナーを追加したいブランチで、リポジトリのルート、docs/、.github/ のいずれかのディレクトリに CODEOWNERS という新しいファイルを作成してください。
各CODEOWNERSファイルは、リポジトリ内の単一のブランチにコードオーナーを割り当てます。 したがって、たとえばmasterブランチのコードベースには@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フォーマットが使われます。 たとえば user@example.com のような、ユーザの GitHub Enterprise アカウントに追加されたメールアドレスでユーザを参照することもできます。
CODEOWNERS ファイルの例
# これはコメントです。
# 各行はファイルパターンの後に一人以上のオーナーが続きます。
# これらのオーナーは、リポジトリ中のすべてに対する
# デフォルトのオーナーになります。 後のマッチが優先されないかぎり、
# 誰かがプルリクエストをオープンすると、
# @global-owner1と@global-owner2にはレビューがリクエストされます。
* @global-owner1 @global-owner2
# 順序は重要です。最後にマッチしたパターンが最も
# 高い優先度を持ちます。 誰かがJSファイルだけを変更する
# プルリクエストをオープンすると、@js-ownerだけにレビューが
# リクエストされ、グローバルのオーナーにはリクエストされません。
*.js @js-owner
# メールアドレスの方が良ければ、そちらを使うこともできます。 それらは
# コミット作者のメールの場合と同じようにユーザの
# ルックアップに使われます。
*.go docs@example.com
# この例では、@doctocatはリポジトリのルートにある
# build/logs及びそのサブディレクトリ内のすべてのファイルの
# オーナーです。
/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