Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

コードオーナーについて

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

コード オーナーは、GitHub Free や Organization 向けの GitHub Free のパブリック リポジトリ内で、および GitHub Pro、GitHub Team、GitHub Enterprise Cloud,、GitHub Enterprise Server のパブリック リポジトリとプライベート リポジトリ内で定義することができます。

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

コード所有者には、リポジトリへの書き込み権限を持っている人を指定する必要があります。 コード所有者が Team である� �合は、Team を表示できる必要があり、Team の個々のメンバーが直接書き込みアクセス許可を既に持っている� �合でも、Organization のメンバーシップまたは別の Team メンバーシップを通じて、Team が書き込みアクセス許可を持っている必要があります。

コードオーナーについて

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

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

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

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

CODEOWNERSファイルの� �所

CODEOWNERS ファイルを使うには、リポジトリのコード所有者を追� するブランチのルート、docs/、または .github/ ディレクトリに、CODEOWNERS という名前の新しいファイルを作成します。

各CODEOWNERSファイルは、リポジトリ内の単一のブランチにコードオーナーを割り当てます。 したがって、異なるブランチに対して異なるコード所有者を割り当てることができます (たとえば、既定のブランチのコード ベースには @octo-org/codeowners-teamgh-pages ブランチ上の GitHub Pages サイトには @octocat)。

コードオーナーがレビューのリクエストを受け取るためには、CODEOWNERS ファイルがプルリクエストの base ブランチになければなりません。 たとえば、リポジトリの gh-pages ブランチ上 の .js ファイルのコード所有者として @octocat を割り当てた� �合、 .js ファイルの変更に関する pull request がヘッド ブランチと gh-pages の間で開かれると、@octocat はレビュー要求を受け取ります。

CODEOWNERS ファイルのサイズ

CODEOWNERS ファイルのサイズは、3 MB 未満でなければなりません。 この制限を超える CODEOWNERS ファイルは読み込まれません。つまり、コード所有者の情� �は示されず、pull request での変更のレビューは、適切なコード所有者に要求されません。

CODEOWNERS ファイルのサイズを小さくするには、ワイルドカード パターンを使って複数のエントリを 1 つのエントリにまとめることを検討してく� さい。

CODEOWNERSの構文

警告: gitignore ファイルには、CODEOWNERS ファイルでは "動作しない" いくつかの構文ルールがあります。

  • # で始まるパターンは、コメントではなくパターンとして扱われるように、\ を使ってエスケープします
  • パターンを否定するには、! を使います
  • 文字範囲を定義するには、[ ] を使います

CODEOWNERS ファイルでは、gitignore ファイルで使われているルールと同じルールのほとんどに従っているパターンを使います。 パターンの後には、標準の @username または @org/team-name 形式を使って、GitHub の 1 つ以上のユーザー名または Team 名が続きます。 ユーザーとチー� は、チー� のメンバーが既にアクセス権を持っている� �合でも、リポジトリへの明示的な write アクセス権を持っている必要があります。

your GitHub Enterprise Server instance のアカウントに追� されたメール アドレスで、ユーザーを参照することもできます (例: user@example.com)。 「Enterprise Managed Users について

GitHub では大文字と小文字を区別するファイル システ� が使われているため、CODEOWNERS のパスでは大文字と小文字が区別されます。 CODEOWNERS は GitHub によって評価されるため、大文字と小文字が区別されないシステ�  (macOS など) であっても、CODEOWNERS ファイルのパスとファイルでは大文字と小文字が正しく使い分けられている必要があります。

CODEOWNERS ファイルのいずれかの行に無効な構文が含まれている� �合、そのファイルは検出されず、レビューの要求には使われません。

CODEOWNERS ファイルの例

# 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 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

CODEOWNERS とブランチの保護

リポジトリの所有者は、ブランチ保護ルールを追� して、変更されたコードが変更されたファイルの所有者によって確実にレビューされるようにすることができます。 詳細については、「保護されたブランチについて」を参照してく� さい。

参考資料