# コードオーナーについて
CODEOWNERS ファイルを使い、リポジトリ中のコードに対して責任を負う個人あるいは Team を指定できます。
コード所有者には、リポジトリへの書き込み権限を持っている人を指定する必要があります。 コード所有者が Team である場合は、Team を表示できる必要があり、Team の個々のメンバーが直接書き込みアクセス許可を既に持っている場合でも、Organization のメンバーシップまたは別の Team メンバーシップを通じて、Team が書き込みアクセス許可を持っている必要があります。
## コードオーナーについて
コードオーナーは、他者が所有するコードを変更するプルリクエストをオープンすると、自動的にレビューをリクエストされます。 コードオーナーはドラフトのプルリクエストのレビューを自動的にリクエストされません。 ドラフトプルリクエストの詳細については、[Pull Request](/ja/enterprise-server@3.21/pull-requests/reference/pull-requests#draft-pull-requests)をご覧ください。 ドラフトのプルリクエストをレビュー用としてマークすると、コードオーナーに自動的に通知されます。 プルリクエストをドラフトに変換する場合、通知を既にサブスクライブしているユーザーは自動的にサブスクライブ解除されません。 詳しくは、「[プルリクエストのステージの変更](/ja/enterprise-server@3.21/pull-requests/how-tos/create-pull-requests/changing-the-stage-of-a-pull-request)」をご覧ください。
管理者あるいはオーナー権限を持つ誰かがレビュー必須を有効化した場合、作者がリポジトリ中でプルリクエストをマージできるための条件としてコードオーナーからの承認を必須とすることもできます。 詳しくは、「[保護されたブランチについて](/ja/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging)」をご覧ください。
ファイルにコードオーナーがいる場合、プルリクエストをオープンする前にコードオーナーを確認できます。 リポジトリでファイルを参照し、 上にカーソルを合わせると、codeownership の詳細を含むツール ヒントが表示されます。
## CODEOWNERSファイルの場所
CODEOWNERS ファイルを使うには、コードのオーナーを追加するブランチにおいて、リポジトリの `CODEOWNERS`、root または `.github/` ディレクトリに、`docs/` という名前の新しいファイルを作成します。
`CODEOWNERS`ファイルが複数の場所に存在する場合、GitHubはその順序でそれらを検索し、最初に見つけたファイルを使用します。
各CODEOWNERSファイルは、リポジトリ内の単一のブランチにコードオーナーを割り当てます。 そのため、既定のブランチのコード ベースの`@octo-org/codeowners-team`や、`@octocat` ブランチのGitHub Pages サイトの`gh-pages`など、ブランチごとに異なるコード所有者を割り当てることができます。
コードオーナーがレビューのリクエストを受け取るためには、CODEOWNERS ファイルがプルリクエストの base ブランチになければなりません。 たとえば、リポジトリの `@octocat` ブランチ上 の *.js* ファイルのコード所有者として `gh-pages` を割り当てた場合、 `@octocat` ファイルの変更に関する pull request がヘッド ブランチと \_\_ の間で開かれると、`gh-pages` はレビュー要求を受け取ります。
## CODEOWNERS とフォーク
レビュー要求をトリガーするには、pull request のベース ブランチからの `CODEOWNERS` のバージョンを使用します。 基本ブランチは、pull request がマージされた場合に pull request が変更するブランチです。
フォークからpull requestを作成し、ベース ブランチがアップストリーム リポジトリにある場合、pull request はアップストリーム リポジトリ内のそのブランチの `CODEOWNERS` ファイルを使用します。 ベース ブランチがフォーク内のブランチである場合、pull request はフォーク内のそのブランチの `CODEOWNERS` ファイルを使用しますが、これは、コード所有者が `write` のアクセス権を持つフォークに追加された場合にのみレビュー要求をトリガーします。
の上にマウス ポインターを置いてファイルを担当するユーザーを表示すると、`CODEOWNERS` ファイルの情報が、どのリポジトリのどのブランチにあるかを確認できます。
## CODEOWNERS ファイルのサイズ
CODEOWNERS ファイルのサイズは、3 MB 未満でなければなりません。 この制限を超える CODEOWNERS ファイルは読み込まれません。つまり、コード所有者の情報は示されず、pull request での変更のレビューは、適切なコード所有者に要求されません。
CODEOWNERS ファイルのサイズを小さくするには、ワイルドカード パターンを使って複数のエントリを 1 つのエントリにまとめることを検討してください。
## CODEOWNERSの構文
> \[!WARNING]
> gitignore ファイルには、CODEOWNERS ファイルでは "動作しない" いくつかの構文ルールがあります。\_\_
> \*
> `#` で始まるパターンは、コメントではなくパターンとして扱われるように、`\` を使ってエスケープしても動作しない
>
> * パターンを否定するのに `!` を使用しても動作しない
> * 文字範囲を定義するのに `[ ]` を使用しても動作しない
CODEOWNERS ファイルでは、[gitignore](https://git-scm.com/docs/gitignore#_pattern_format) ファイルで使われているルールと同じルールのほとんどに従っているパターンを使います。 パターンの後に、標準のGitHubまたは`@username`形式を使用して、1 つ以上の`@org/team-name`ユーザー名またはチーム名が続きます。 ユーザーとチームは、チームのメンバーが既にアクセス権を持っている場合でも、リポジトリへの明示的な `write` アクセス権を持っている必要があります。
> \[!NOTE]
> チームを使用する場合、コード所有者にできるのは組織チームだけです。 エンタープライズ チームは、コード所有者としてサポートされていません。 「[Enterprise 内の Teams](/ja/enterprise-server@3.21/admin/concepts/enterprise-fundamentals/teams-in-an-enterprise)」を参照してください。
同じパターンを持つ複数のコード所有者を照合する場合は、すべてのコード所有者が同じ行に存在する必要があります。 コード所有者が同じ行にない場合、パターンに合致するのは最後に指定されたコード所有者のみです。
は、`user@example.com`など、アカウントに追加された電子メール アドレスでユーザーを参照することもできます。
CODEOWNERS のパスでは、大文字と小文字が区別されます。これは、GitHub が大文字と小文字を区別するファイルシステムを使用しているためです。 CODEOWNERS は GitHubによって評価されるため、大文字と小文字が区別されないシステム (macOS など) でも、CODEOWNERS ファイルで正しく大文字と小文字が区別されるパスとファイルを使用する必要があります。
CODEOWNERS ファイルのいずれかの行に無効な構文が含まれている場合、その行はスキップされます。 リポジトリ内の CODEOWNERS ファイルに移動すると、エラーが強調表示されていることがわかります。 リポジトリの CODEOWNERS ファイル内のエラーの一覧には、API からアクセスすることもできます。 詳しくは、「[リポジトリの REST API エンドポイント](/ja/enterprise-server@3.21/rest/repos/repos#list-codeowners-errors)」をご覧ください。
存在しない、またはアクセスが不十分なユーザーまたはチームを指定した場合、コード オーナーは割り当てられません。
### CODEOWNERS ファイルの例
```text
# This is a comment.
# Each line is a file pattern followed by one or more owners.
# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence,
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.
* @global-owner1 @global-owner2
# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only @js-owner and not the global
# owner(s) will be requested for a review.
*.js @js-owner #This is an inline comment.
# You can also use email addresses if you prefer. They'll be
# used to look up users just like we do for commit author
# emails.
*.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
# The `docs/*` pattern will match files like
# `docs/getting-started.md` but not further nested files like
# `docs/build-app/troubleshooting.md`.
docs/* docs@example.com
# In this example, @octocat owns any file in an apps directory
# anywhere in your repository.
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
# 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 a `/logs` directory such as
# `/build/logs`, `/scripts/logs`, and `/deeply/nested/logs`. Any changes
# in a `/logs` directory will require approval from @octocat.
**/logs @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. Without an owner, changes
# to `apps/github` can be made with the approval of any user who has
# write access to the repository.
/apps/ @octocat
/apps/github
# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as this subdirectory has its own owner @doctocat
/apps/ @octocat
/apps/github @doctocat
```
## CODEOWNERS とブランチの保護
リポジトリの所有者は、ブランチ保護ルールを更新して、変更されたコードが変更されたファイルの所有者によって確実にレビューされるようにすることができます。 ブランチ保護規則を編集し、「コード所有者からのレビューを要求する」 オプションを有効にします。 詳しくは、「[保護されたブランチについて](/ja/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)」をご覧ください。
> \[!NOTE]
> コード所有者のレビューが必要な場合、"いずれかの" 所有者による承認があればこの要件を十分に満たせます。\_\_ たとえば、CODEOWNERS ファイルに次の行が含まれているとします。
>
> ```text
> *.js @global-owner1 @global-owner2
> ```
>
> つまり、JavaScript ファイルへの変更は `@global-owner1`*または*`@global-owner2` によって承認できますが、\_両方\_による承認は必要ありません。
承認されていない変更からリポジトリを完全に保護するには、CODEOWNERS ファイル自体の所有者を定義する必要もあります。 最も安全な方法は、リポジトリの`.github`ディレクトリに CODEOWNERS ファイルを定義し、リポジトリ所有者を CODEOWNERS ファイル (`/.github/CODEOWNERS @owner_username`) またはディレクトリ全体 (`/.github/ @owner_username`) の所有者として定義することです。
ブランチ保護規則の代わりに、ルールセットを作成できます。 ルールセットには、状態などのブランチ保護規則よりもいくつかの利点があり、管理者アクセスを必要とせずに検出可能性が向上します。 同時に複数のルールセットを適用することもできます。 詳しくは、「[ルールセットについて](/ja/enterprise-server@3.21/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)」をご覧ください。
## 参考資料
* [新しいファイルの作成](/ja/enterprise-server@3.21/repositories/working-with-files/managing-files/creating-new-files)
* [コラボレーターを個人リポジトリに招待する](/ja/enterprise-server@3.21/repositories/managing-your-repositorys-settings-and-features/repository-access-and-collaboration/inviting-collaborators-to-a-personal-repository)
* [Organization のリポジトリへの個人のアクセスを管理する](/ja/enterprise-server@3.21/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-an-individuals-access-to-an-organization-repository)
* [Organization のリポジトリに対するチームのアクセスを管理する](/ja/enterprise-server@3.21/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-team-access-to-an-organization-repository)
* [プルリクエストレビューを表示する](/ja/enterprise-server@3.21/pull-requests/how-tos/review-pull-requests/viewing-a-pull-request-review)