ユーザーが organization 内のリポジトリを使用する方法の管理

リポジトリのライフサイクルにおける主要なイベント (リポジトリを作成または削除できるユーザーなど) を管理するために、リポジトリ ポリシーを作成できます。 リポジトリ ポリシーは、影響を受けるユーザーと対象となるリポジトリを柔軟に制御できる制限のコレクションです。

リポジトリ ポリシーでは、以下を制限できます。

• 新しいリポジトリと可視性の変更に対して許可する可視性。
• リポジトリを作成できるユーザー。
• リポジトリを削除できるユーザー。
• リポジトリを organization の外部に委譲できるユーザー。
• ユーザーがリポジトリに名前を付ける方法。

例

リポジトリ ポリシーを使って、次のような操作を行うことができます。

• すべての新しいリポジトリが、kebab-case などの特定の名前付け規則を使うようにする。
• Organization 管理者以外がリポジトリを削除できないようにする。
• Enterprise の "オープンソース" organization 内でのみパブリック リポジトリを作成できるようにする。
• メタデータが失われる可能性を避けるために、パブリック リポジトリがプライベート リポジトリに変更されないようにする。

リポジトリをターゲットにするにはどうすればよいですか?

リポジトリ ポリシーはカスタム リポジトリ プロパティと併用することをお勧めします。 カスタム プロパティをリポジトリに追加すると、ポリシーでそれらのリポジトリを柔軟にターゲットにすることができます。

たとえば、運用データやその他の機密情報を含むリポジトリにマークするプロパティを追加し、誰もそれらのリポジトリを公開できないようにすることができます。

カスタム プロパティを作成および設定するには、「組織内リポジトリのカスタム プロパティの管理」を参照してください。

カスタム プロパティではなく、リポジトリの一覧から選ぶか、fnmatch 構文を使って特定の名前付けパターンを持つリポジトリをターゲットにすることができます。

他のポリシーとの相互作用

使用できる制限の一部は、organization または Enterprise の設定の [Member privileges] ページで設定されるポリシーと重複しています。

リポジトリ ポリシーを作成しても、既存の "メンバー特権" ポリシーはオーバーライドされません。 そうではなく、ポリシーは追加的なものであるため、最も制限が厳しいバージョンのポリシーが適用されます。 これは、メンバー特権ポリシーと、Enterprise または organization レベルで作成された他のリポジトリ ポリシーの両方に適用されます。

メンバー特権ポリシーと比較すると、リポジトリ ポリシーにはいくつかの利点があります。

• Organization とリポジトリをより柔軟にターゲットにすることができます。
• これにより、ポリシーをバイパスするオプションを特定のアクターに与えることができます。

リポジトリ ポリシーの作成

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。
2. 組織の隣の [設定] をクリックします。
3. ページの左側のサイドバーで、 [Policies] をクリックします。
4. [Policies] で、[Repository] をクリックします。
5. [新しいポリシー] をクリックします。
6. 新しいポリシーを構成し、[Create] をクリックします。 ヘルプが必要な場合は、次のサブセクションを参照してください。

ポリシー名

ポリシーの目的を伝えるために、わかりやすいものを使ってください。 (例: Prevent public repos on production)。

適用状態

作成時にポリシーを適用したくない場合は、[Disabled] に設定します。 それ以外の場合は、[Active] に設定します。

許可リスト

このポリシーの制限をバイパスできるロールを選びます。

目標値

ポリシーを適用する organization 内のリポジトリを選びます。 すべてのリポジトリを選ぶ、既存のリポジトリを選ぶ、または現在と将来のリポジトリの名前またはカスタム プロパティを指定して動的規則を作成することができます。

名前を指定して動的リストを設定する場合は、fnmatch 構文を使って 1 つ以上の名前付けパターンを追加します。

• たとえば、文字列 *open-source は、名前が open-source で終わるリポジトリと一致します。 構文の詳細については、「リポジトリのルールセットの作成」を参照してください。
• 必要に応じて、許可リストに含まれない、ユーザーが選んだリポジトリの名前を変更できないようにすることができます。 また、[Policies] セクションで名前の形式を制御することもできます。

ポリシー

含める制限を選びます。 ポリシーがアクティブな場合、制限は対象のすべてのリポジトリに適用されますが、許可リストに含まれるユーザーまたはチームは制限をバイパスできます。

[Restrict names] ポリシーを選んだ場合は、正規表現構文を使って、リポジトリ名が一致する必要がある、または一致してはならないパターンを設定する必要があります。 たとえば、kebab-case の名前付けを適用するパターンは ^([a-z][a-z0-9]*)(-[a-z0-9]+)*$ のようになります。

• パターンは RE2 構文をサポートしています。 Google の構文ガイドを参照してください。
• 式を検証するには、[Test pattern] をクリックし、パターンとテスト値を入力します。

ポリシーのバイパスの委任

リポジトリ ポリシーに対して委任されたバイパスを使うと、リポジトリの削除と可視性の変更について、リポジトリ ポリシーをバイパスできるユーザーを制御できます。

委任されたバイパスでは、リポジトリ管理者は要求を送信して、リポジトリの可視性の変更またはリポジトリの削除を行う必要があります。 要求は指定されたレビュー担当者グループに送信され、レビュー担当者はリポジトリ ポリシーをバイパスする要求を承認または拒否します。

リポジトリ ポリシーをバイパスする要求が承認されると、要求の変更はすぐに完了します。 要求が拒否された場合、要求された変更は行われませんが、再度要求できます。

委任されたバイパスを構成するには、Enterprise 所有者または organization 所有者が最初に "バイパス リスト" を作成します。 バイパス リストには、チームやリポジトリの管理者など、リポジトリ ポリシーをバイパスする要求を監視する特定のロールとチームが含まれます。 詳しくは、「ユーザーが Enterprise 内のリポジトリを使用する方法の管理」をご覧ください。

バイパス要求の管理

プッシュ ルールをバイパスする要求の管理

バイパス特権のすべての要求は、ポリシーの設定にある [Bypass Requests] ページで表示および管理できます。

承認者 (バイパス リストのメンバー)、要求者 (要求を作成する投稿者)、期間、および状態によって要求をフィルター処理できます。 要求には次の状態が割り当てられます。

状態	説明
Cancelled	要求は投稿者によって取り消されました。
Completed	要求が承認され、コミットがリポジトリにプッシュされました。
Denied	要求が審査され否認されました。
Expired	要求の有効期限が切れました。 要求は 7 日間有効です。
Open	要求はまだレビューされていないか、承認されていますが、コミットがリポジトリにプッシュされていません。

投稿者が制限された内容などコミットをプッシュするバイパス権限を要求すると、バイパス リストのメンバーはすべて、要求へのリンクを含む電子メールによる通知を受信します。 その後、バイパス リストのメンバーは、要求の有効期限が切れる前に、要求を確認して承認または拒否する 7 日間があります。

投稿者は電子メールで決定を通知され、必要なアクションを実行する必要があります。 要求が承認された場合、投稿者は制限された内容などコミットをリポジトリにプッシュできます。 要求が拒否された場合、投稿者はコミットから制限された内容を削除して、コミットをリポジトリに正常にプッシュする必要があります。