はじめに
「レビューしてもらうために、毎回検索欄からレビュワーを探すのが面倒だ…」
「PRを作るたびに、誰に割り当てるべきか迷う…」
こんな悩みを抱えていませんか？
手動でレビュワーをアサインする作業は時間を取られる上に、ミスや漏れが発生することもあります。
今回は、このような煩雑な作業を自動化できるGitHubの機能「CODEOWNERS」を紹介します！
CODEOWNERSを使えば、特定のファイルやフォルダに責任者を割り当て、プルリクエスト（PR）作成時に自動でレビュワーをアサインできるようになります。これにより、手動作業を大幅に削減し、レビューをスムーズに進めることが可能です!
今回解説すること
CODEOWNERSを導入することで、PRごとにレビュワーを割り当てる手間を自動化し、チーム開発の効率を向上させることができます。以下では、CODEOWNERSの基本的な仕組みや具体的な設定方法を解説します。
想定読者
-
チーム開発をしているエンジニア
レビュワーを手動でアサインする作業に手間を感じている人。 -
リポジトリに関する権限を持つ人
実際にレビューする人数は限られているが、リポジトリの権限は多くの人が持っている状態で開発している人。
1. CODEOWNERSとは？
CODEOWNERSは、特定のリポジトリやコードに対して責任者（オーナー）を設定できるGitHubの機能です。
ファイルごとに責任者を明確化することで、以下のようなメリットがあります：
- 自動アサイン：PR作成時に、設定したオーナーが自動的にレビュワーとして割り当てられる。
- 責任の明確化：各コードやディレクトリに対して誰が責任を持つべきかが一目で分かる。
- 品質管理の向上：特定の専門家がレビューする仕組みを構築できる。
たとえば、
*.jsファイルはフロントエンド担当者にアサイン-
*.mdファイルはドキュメント担当者にアサイン
といった柔軟な設定が可能です。
2. CODEOWNERSの設定方法
準備：CODEOWNERSファイルの作成
- リポジトリの
rootディレクトリ、.githubフォルダ、またはdocsフォルダにCODEOWNERSという名前のファイルを作成します。 - ファイルには以下の形式でルールを記述します：
# ファイルまたはディレクトリごとのオーナーを指定
*.js @frontend_user
/docs/ @docs_team
具体例：設定ファイル
以下は例です：
# 全体の責任者
* @repo_admin
# フロントエンドファイルの責任者
*.js @frontend_user
# ドキュメントの責任者
/docs/ @docs_team
例えば、この場合、/docs/ 内のファイルは必ず@docs_teamが確認することになります。
ただ、この場合に注意しなければいけないのは/docs/内にある jsファイル も @docs_team がアサインされることになるということです。
なので、拡張子単位でオーナーを規定すると、そのような問題が発生しなくていいかなと思います。
公式のソース(翻訳)
# これはコメントです。
# 各行はファイルパターンと1人以上の所有者を表しています。
# これらの所有者は、リポジトリ内のすべてのデフォルトの所有者となります。
# 後の一致が優先されない限り、誰かがプルリクエストを作成すると、
# @global-owner1 と @global-owner2 がレビューを依頼されます。
* @global-owner1 @global-owner2
# 順序は重要です。最後に一致したパターンが最も優先されます。
# 誰かがJSファイルのみを変更するプルリクエストを作成した場合、
# グローバル所有者ではなく、@js-owner のみがレビューを依頼されます。
*.js @js-owner #これはインラインコメントです。
# 必要に応じてメールアドレスも使用できます。
# メールアドレスは、コミットの著者のメールアドレスと同様にユーザーを検索するために使用されます。
*.go docs@example.com
# チームもコードオーナーとして指定できます。
# チームは @org/team-name の形式で識別する必要があります。
# チームはリポジトリに明示的な書き込み権限を持っている必要があります。
# この例では、octo-org 組織の octocats チームがすべての .txt ファイルを所有します。
*.txt @octo-org/octocats
# この例では、@doctocat はリポジトリのルートにある build/logs ディレクトリおよび
# そのサブディレクトリ内のすべてのファイルを所有します。
/build/logs/ @doctocat
# `docs/*` パターンは `docs/getting-started.md` のようなファイルには一致しますが、
# `docs/build-app/troubleshooting.md` のようにさらにネストされたファイルには一致しません。
docs/* docs@example.com
# この例では、リポジトリ内の任意の場所にある apps ディレクトリ内のすべてのファイルを
# @octocat が所有します。
apps/ @octocat
# この例では、@doctocat はリポジトリのルートにある `/docs` ディレクトリおよび
# そのサブディレクトリ内のすべてのファイルを所有します。
/docs/ @doctocat
# この例では、`/scripts` ディレクトリ内の任意の変更には @doctocat または @octocat の
# 承認が必要です。
/scripts/ @doctocat @octocat
# この例では、@octocat は `/logs` ディレクトリ内の任意のファイルを所有します。
# 例えば、`/build/logs`、`/scripts/logs`、`/deeply/nested/logs` などです。
# `/logs` ディレクトリ内の任意の変更には @octocat の承認が必要です。
**/logs @octocat
# この例では、@octocat はリポジトリのルートにある `/apps` ディレクトリ内の任意のファイルを
# 所有します。ただし、`/apps/github` サブディレクトリは所有者が空なので、
# このサブディレクトリへの変更はリポジトリに書き込み権限を持つ任意のユーザーが承認可能です。
/apps/ @octocat
/apps/github
# この例では、@octocat はリポジトリのルートにある `/apps` ディレクトリ内の任意のファイルを
# 所有します。ただし、このサブディレクトリ `/apps/github` は独自の所有者 @doctocat を持っています。
/apps/ @octocat
/apps/github @doctocat
3. つまづきポイント
-
1行1ルールの制限
以下のように複数行で同じパターンのルールを指定すると、最後のルールだけが適用されます：
* @user_A
* @user_B
この場合、@user_BだけがCODEOWNERSとして設定されるため、1行でまとめる必要があります：
* @user_A @user_B
4. 応用例・発展的な内容
Draft PRを使用する
PRを作成する際に「Draft PR」として作成すれば、レビュワーに不要な通知を送らずに済みます。本格的なレビュー前に下書きを公開することで、チーム内での意見交換や準備を進めることができます。
マージルールと組み合わせる
- CODEOWNERSによるレビューが必須となるように、GitHubの「Branch Protection Rules」に設定を追加します。
- 具体的には、「Require review from Code Owners」を有効にすることで、責任者が承認しない限りマージできないルールを作ることができます。
まとめ
これで、幸せなプルリク生活が待ってるね。
補足
参考記事
FAQ
-
Q: CODEOWNERSは複数のリポジトリで共通化できますか？
A: CODEOWNERSファイルはリポジトリごとに設定する必要があります。ただし、テンプレートとして同じファイルをコピーすれば運用が楽になります。 -
Q: CODEOWNERSで指定したユーザーが通知を受け取らない場合は？
A: 該当ユーザーにリポジトリへの「Write」または「Admin」権限があるか確認してください。また、mainにmergeされていることを確認してください。