コードの所有者
コード所有者は、コードベースの特定の部分を担当するメンバーです。コード所有者は、CODEOWNERS という名前の特別なファイルに定義され、表示されます。責任リストを使用すると、プロジェクトのさまざまな部分の担当者を広範囲に把握できますが、CODEOWNERS ファイルを使用すると、リポジトリ内の特定のパスまたはファイルについて質問がある場合の連絡先を見つけることができます。
さらに、CODEOWNERS ファイルを使用すると、品質ゲートとしてコード所有者の承認が必要な保護されたブランチへのマージリクエストを効率化することができます。誰かがマージリクエストを送信すると、変更されたファイルのコード所有者は自動的にレビューを要求され、コミッターが変更をマージできるようになる前に変更を承認する必要があります。
CODEOWNERS ファイルの作成と検索
CODEOWNERS ファイルは Git リポジトリの一部であり、リポジトリ内の特定のパスまたはファイルの所有者を概説します。
Space で新しいリポジトリを作成すると、CODEOWNERS ファイルテンプレートが自動的に作成されます。既存のリポジトリでは、ファイルを自分で作成する必要がある場合があります。CODEOWNERS ファイルは次の 2 つの場所で作成できます。
リポジトリのルートディレクトリ内
.space/ディレクトリ内
コードの所有権を定義するには、以下で説明する構文に従って、CODEOWNERS ファイルにルールを手動で追加する必要があります。
CODEOWNERS ファイルはブランチ固有であるため、次の点に注意してください。
保護されたターゲットブランチに対してマージリクエストが送信されると、そのターゲットブランチの CODEOWNERS ファイルが適用されます。CODEOWNERS ファイルはマージリクエストのターゲットブランチ上に存在する必要があります。
各ブランチは独自の CODEOWNERS ファイルを持つことができます。つまり、ブランチごとに異なるコード所有者を割り当てることができます。
CODEOWNERS ファイルの構文
CODEOWNERS ファイルでは、各行がルールを表します。ルールはパスまたはファイルのパターンで始まり、その後に 1 人以上の所有者が続きます。
通常、パターンは
.gitignoreファイルに使用されるのと同じ構文に従います。docs/のようなワイルドカードは、docs/**/*.mdのようなグロブパターンと同様にサポートされています。所有者は、Space のユーザー名、検証済みのメールアドレス、またはプロジェクト内のロールとして指定できます。チームも指定可能です。
デフォルトでは、CODEOWNERS ファイル自体は、プロジェクト管理者のロールを割り当てられたチームメンバーによって所有されます。
マージリクエストの承認には順序が重要です。ルールは上から下に処理されるため、最後に一致したパターンが優先されます。ファイルの先頭にはより一般的なルールを追加し、最後のほうにはより具体的なルールを追加することをお勧めします。以下のファイル例では、
/web/assets/にあるファイルは、たとえ Paul と Rachel が所有する*.jsファイルであっても、Andrew の承認が必要になります。
CODEOWNERS ファイルの例:
# Each line represents a rule, followed by a list of members.
# These members are the default owners for all files that match the specified pattern.
# The pattern generally follows the same syntax used for .gitignore files.
# The last matching rule always wins; those that appear lower in the file take precedence over rules that appear higher up.
# Specify owners by their username, email, or role assignment in the project.
# Examples:
# Member with username "Travis.Wickett" and member with email "rachel.pardey@somemail.com"
# own any JavaScript file in the repository
*.js Travis.Wickett rachel.pardey@somemail.com
# Jake handles Gradle files
*.gradle Jake.Miller
# Andrew owns all files under "/web/assets" directory at the repository root and all its subdirectories
/web/assets/ Andrew.Nelson
# All members who are assigned the Project Collaborator role own any file under docs/ directory
# anywhere in the repository, but not further nested files
docs/* "Project Collaborator"
# This file itself is owned by members who are assigned the Project Admin role in this project.
CODEOWNERS "Project Admin"マージリクエストでのコード所有者の承認
CODEOWNERS ファイルを設定している場合は、マージリクエストの品質ゲートの 1 つとしてコード所有者の承認要件を有効にすることができます。
リポジトリ設定の保護されたブランチタブで、保護されたブランチルールを作成 (または編集) し、品質ゲートのコード所有者の承認を必要とするチェックボックスをオンにします。
詳細については、ブランチとマージ制限のセットアップを参照してください。
関連ページ：
プロジェクトに参加する
あるプロジェクトに貢献を開始したい場合は、そのプロジェクトに参加する必要があります。つまり、そのプロジェクトのメンバーになる必要があります。貢献しようとしているプロジェクトに移動します。すでにメンバーである場合は、プロジェクトのページのプロジェクトメンバーにリストされます。そうでない場合は、プロジェクト管理者に連絡してメンバーシップを依頼してください。プロジェクト管理者を確認するには、プロジェクトページでメンバーウィジェットをクリックします。プロジェクトを探す：すべてのプロジェクトは名前で見つ
ブランチとマージ制限のセットアップ
プロジェクトロールを使用すると、リポジトリでの書き込み権限と読み取り権限を管理できますが、それだけではコードの品質と効率的なコラボレーションを確保するには不十分な場合があります。ブランチ保護設定を使用すると、リポジトリ全体に過剰な制限を課すことなく、重要なブランチを不注意な操作や望ましくない変更から保護できます。特定のブランチのセキュリティルールを作成すると、次のことが可能になります。誤ってブランチが削除されるのを防ぎます。ブランチをプッシュまたは強制的にプッシュできる人を制限します。ブランチに...
Git サブツリー
Git サブツリーを使用すると、ある Git リポジトリの内容をサブディレクトリとして別のリポジトリに含めることができます。別のリポジトリを別個のエンティティとして保持しながら、別のリポジトリのコンテンツと履歴を自分のリポジトリに組み込むことができます。これは、外部コードベースへの変更、更新のプル、変更のプッシュをすべてメインリポジトリ内から行うことができることを意味します。Git サブツリーを使用すると、複数のリポジトリを 1 つのリポジトリに結合できるため、依存関係の管理、外部コードベースの...