ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

コードオーナーについて

CODEOWNERS ファイルを使い、リポジトリ中のコードに対して責任を負う個人あるいは Team を指定できます。

You can define code owners in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see "GitHub's products."

ここには以下の内容があります:

管理者あるいはオーナー権限を持つ人は、リポジトリ中に CODEOWNERS ファイルをセットアップできます。

コードオーナーに指定する人は、リポジトリへの書き込み権限を持っていなければなりません。 コードオーナーが Team である場合、Team の個々のメンバーが直接、書き込み権限を持っているときでも、Organization のメンバーであることまたは他の Team のメンバーであることを通じて、Team が書き込み権限を持っている必要があります。

コードオーナーについて

コードオーナーは、他者が所有するコードを変更するプルリクエストをオープンすると、自動的にレビューをリクエストされます。 コードオーナーはドラフトのプルリクエストのレビューを自動的にリクエストされません。 ドラフトのプルリクエストに関する詳しい情報については「プルリクエストについて」を参照してください。 コードオーナーはドラフトのプルリクエストのレビューを自動的にリクエストされません。 プルリクエストをドラフトに変換する場合、通知を既にサブスクライブしているユーザは自動的にサブスクライブ解除されません。 詳しい情報については、「プルリクエストのステージを変更する」を参照してください。

管理者あるいはオーナー権限を持つ誰かがレビュー必須を有効化した場合、作者がリポジトリ中でプルリクエストをマージできるための条件としてコードオーナーからの承認を必須とすることもできます。 詳しい情報については、「プルリクエストの必須レビューを有効にする」を参照してください。

If a team has enabled code review assignments, the individual approvals won't satisfy the requirement for code owner approval in a protected branch. 詳しい情報については、「Team のコードレビューの割り当てを管理する」を参照してください。

ファイルにコードオーナーがいる場合、プルリクエストをオープンする前にコードオーナーを確認できます。 In the repository, you can browse to the file and hover over .

リポジトリ内のファイルのコードオーナー

CODEOWNERSファイルの場所

CODEOWNERS ファイルを使うためには、コードオーナーを追加したいブランチで、リポジトリのルート、docs/.github/ のいずれかのディレクトリに CODEOWNERS という新しいファイルを作成してください。

各CODEOWNERSファイルは、リポジトリ内の単一のブランチにコードオーナーを割り当てます。 Thus, you can assign different code owners for different branches, such as @octo-org/codeowners-team for a code base on the default branch and @octocat for a GitHub Pages site on the gh-pages branch.

コードオーナーがレビューのリクエストを受け取るためには、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 アカウントに追加されたメールアドレスでユーザを参照することもできます。

CODEOWNERS ファイルのいずれかの行に無効な構文が含まれている場合、そのファイルは検出されず、レビューのリクエストには使用されません。 無効な構文には、GitHub に存在しないインラインコメントとユーザ名または Team 名が含まれます。

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

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

参考リンク

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.