👋 We've unified all of GitHub's product documentation in one place! Check out the content for REST API, GraphQL API, and Developers. Stay tuned for a blog post later today.


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

コードオーナーについて

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

コードオーナーは、GitHub Free 及びGitHub FreeのOrganizationのパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのパブリックおよびプライベートリポジトリで定義できます。 詳しい情報については「GitHubの製品」を参照してください。

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

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

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

コードオーナーについて

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

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

Team がコードレビューの割り当てを有効にしている場合、個々の承認は、保護されたブランチでのコードオーナーの承認要件を満たしません。 詳しい情報については、「Team のコードレビューの割り当てを管理する」を参照してください。

ファイルにコードオーナーがいる場合、プルリクエストをオープンする前にコードオーナーを確認できます。 リポジトリで、ファイルを参照して にカーソルを合わせることができます。

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

特定のファイルのオーナーを表示するには、機能プレビューでファイル のコードオーナーを有効にする必要があります。 詳しい情報については「機能プレビューで早期アクセスリリースに触れる」を参照してください。

CODEOWNERSファイルの場所

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

各CODEOWNERSファイルは、リポジトリ内の単一のブランチにコードオーナーを割り当てます。 したがって、たとえばmasterブランチのコードベースには@octo-org/codeowners-teamgh-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 アカウントに追加されたメールアドレスでユーザを参照することもできます。

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

参考リンク

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください