組織内のリポジトリのルールセットを作成する

この記事の内容

組織内の複数のリポジトリを対象にしたルールセットを作成できます。

この機能を使用できるユーザー

Organization owners can create rulesets at the organization level.

はじめに

組織にルールセットを作成して、ユーザーが組織内のリポジトリを操作する方法を制御できます。 どのユーザーが特定のブランチにコミットをプッシュできるか、コミットをどのようにフォーマットする必要があるか、どのユーザーがタグを削除または名前変更できるかといったことを制御できます。 また、ユーザーがリポジトリの名前を変更できないようにすることもできます。

組織のルールセットを作成するときは、fnmatch 構文を使用して、組織内のどのリポジトリ、およびそれらのリポジトリ内のどのブランチまたはタグがルールセットの対象となるかを定義します。 こうすると、各リポジトリに個別のルールセットを作成するよりも、組織内のリポジトリをより迅速にターゲットにすることができます。 詳細については、「分岐、タグ、リポジトリの fnmatch パターンについて」を参照してください。

フォークは、アップストリーム リポジトリからルールセットを継承しません。 ただし、組織が所有するフォークは、他のリポジトリと同様に、作成するルールセットの対象となります。

JSON ファイルを使用して、別のリポジトリまたは組織からルールセットをインポートできます。 これは、複数のリポジトリまたは組織に同じルールセットを適用する場合に便利です。 詳細については、「組織内のリポジトリのルールセットを管理する」を参照してください。

ルールセットを作成するには、次の手順を完了します。

分岐またはタグルールセットの作成

  1. GitHub.com の右上隅にあるプロファイル写真を選択し、次に自分の組織をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [Your organizations] (自分の組織) が濃いオレンジ色の枠線で囲まれています。

  2. 組織の隣の [設定] をクリックします。

  3. 左のサイド バーの [コード、計画、自動化] セクションで、 [リポジトリ] をクリックし、 [リポジトリ ルールセット] をクリックします。

    Organization の設定ページのスクリーンショット。 サイド バーで、[リポジトリ ルールセット] というラベルの付いたリンクがオレンジ色の枠線で囲まれています。

  4. ブランチを対象とするルールセット、またはタグを対象とするルールセットを作成できます。

    • ブランチを対象とするルールセットを作成するには、 [新しいブランチ ルールセット] をクリックします。

    • タグを対象とするルールセットを作成するには、[] を選び、 [新しいタグ ルールセット] をクリックします。

      [ルールセット] ページのスクリーンショット。 [新しいブランチ ルールセット] ボタンの横にドロップダウン メニューが展開され、[新しいタグ ルールセット] というラベルが付いたオプションがオレンジ色の枠線で囲まれています。

  5. [全般] セクションで、ルールセットの名前を入力し、 [無効] を選択して、次の適用ステータスのいずれかをクリックします。

    • アクティブ: ルールセットは作成時に適用されます。
    • 評価: ルールセットは適用されませんが、[ルールの分析情報] ページでルールに違反するアクションと違反しないアクションを監視できます。 詳しくは、「ルールセットの分析情報を表示する」をご覧ください。
    • 無効: ルール セットは、 または評価 に適用されません。

ルールセットに対するバイパス アクセス許可の付与

特定のロール、チーム、またはアプリにルール セットのアクセス許可をバイパスさせることができます。 バイパス アクセスの対象となるのは次のとおりです。

  • リポジトリ管理者または組織の所有者
  • 保守ロール、書き込みロール、または書き込みロールに基づくカスタム リポジトリ ロール
  • Teams
  • GitHub Apps

  1. ルールセットのバイパスのアクセス許可を付与するには、[バイパス リスト] セクションで [バイパスの追加] をクリックします。

  2. 表示される [バイパスの追加] モーダル ダイアログで、バイパスアクセス許可を付与するロール、チーム、またはアプリを検索し、[提案] セクションからロール、チーム、またはアプリを選択し、[選択項目の追加] をクリックします。

  3. 必要に応じて、リポジトリに直接プッシュすることを許可せずにアクターにバイパスを許可するには、[常時] を選択し、[pull request のみ] をクリックします。

    選択したアクターは、リポジトリに変更を加えるために pull request を開く必要があり、これにより、変更を含む明確なデジタル 証跡が作成されます。 アクターは、ブランチ保護をバイパスし、その pull request をマージすることを選択できます。

組織内でターゲットにするリポジトリの選択

ルールセットを使用して、組織内のすべてのリポジトリ、特定の名前付け規則に一致する組織内のリポジトリ、または組織内で手動で選択したリポジトリの一覧をターゲットとして選択できます。

リポジトリが組織レベルで作成されたルールセットのターゲットになっている場合は、組織のオーナーのみがそのルールセットを編集できます。 ただし、リポジトリへの管理者アクセス権を持つユーザー、または "リポジトリ ルールの編集" アクセス許可を含むカスタム ロールを持つユーザーは、リポジトリ レベルで追加のルールセットを作成できます。 これらのルールセット内のルールは、組織レベルで定義されたルールと集約されます。 その結果、新しいルールセットを作成すると、ブランチまたはタグを対象とするルールは、より制限が厳しくなりますが、制限が緩くなることはありません。 ルールセットの作成の詳細については、「ルールセットについて」を参照してください。

組織内のすべてのリポジトリをターゲットにする

組織内のすべてのリポジトリをターゲットにするには、[ターゲット リポジトリ] セクションで [ターゲット: REPOSITORIES] を選択し、[すべてのリポジトリ] をクリックします。

組織内の名前付け規則によるリポジトリのターゲット設定

  1. 名前付け規則による、組織内のリポジトリの動的リストをターゲットにするには、[ターゲット リポジトリ] セクションで [ターゲット: REPOSITORIES] を選択し、[リポジトリの動的リスト] をクリックします。

  2. ターゲット パターンの定義を開始するには、[ターゲット条件] セクションで、[ターゲットの追加] を選択し、[パターンで追加] または [パターンで除外] をクリックします。

  3. 表示されるモーダル ダイアログで、fnmatch 構文を使ってリポジトリの名前付けパターンを入力し、 [包含パターンの追加] または [除外パターンの追加] をクリックします。 fnmatch 構文の詳細については、「fnmatch 構文の使用」を参照してください。

    注: 複数のターゲット条件を同じルールセットに追加できます。 たとえば、パターン *cat* に一致するリポジトリを含め、さらにパターン not-a-cat に一致するリポジトリを明示的に除外できます。

  4. 必要に応じて、ルールセットの構成ページで [ターゲット リポジトリの名前変更を禁止する] を選びます。

プロパティに基づいて組織内のリポジトリをターゲットにする

注: リポジトリのプロパティは公開用ベータ版であり、変更される可能性があります。

カスタム プロパティに基づいて、組織内のリポジトリをターゲットにすることができます。 詳しくは、「組織内リポジトリのカスタム プロパティの管理」を参照してください。

  1. プロパティに基づいて組織内のリポジトリの動的リストをターゲットにするには、[ターゲット リポジトリ] セクションで [ターゲット: REPOSITORIES] を選択し、[プロパティに基づく動的リスト] をクリックします。
  2. ターゲットを追加するには、[ターゲットにする条件] セクションで、[ターゲットの追加] を選択し、[プロパティに基づいて包含] または [プロパティに基づいて除外] をクリックします。
  3. 表示されるモーダル ダイアログで、ドロップダウン メニューからプロパティを選択し、プロパティの値を選択します。
  4. [ターゲットの追加] をクリックします。

組織内のリポジトリを選択してターゲットにする

  1. 組織内の静的で手動で選択されたリポジトリの一覧をターゲットにするには、[ターゲット リポジトリ] セクションで [ターゲット: REPOSITORIES] を選択し、[リポジトリの選択] をクリックします。
  2. 選んだリポジトリの静的一覧をターゲットにするには、[ターゲット条件] セクションで [リポジトリの選択] を選択し、ターゲットにする各リポジトリを検索します。 検索結果から各リポジトリを選びます。

ターゲットにするブランチまたはタグの選択

ブランチまたはタグをターゲットにするには、[ターゲット ブランチ] または [ターゲット タグ] セクションで、[ターゲットの追加] を選び、ブランチまたはタグを含めるまたは除外する方法を選びます。 fnmatch 構文を使って、パターンに基づいてブランチまたはタグを含めたり除外したりできます。 詳しくは、fnmatch 構文の使用に関するページを参照してください。

複数のターゲット条件を同じルールセットに追加できます。 たとえば、既定のブランチを含め、*feature* のパターンに一致するブランチを含めてから、not-a-feature のパターンに一致する特定のブランチを除外することができます。

ブランチまたはタグの保護の選択

[ブランチ保護] または [タグ保護] セクションで、ルールセットに含めるルールを選びます。 ルールを選ぶと、そのルールに追加設定を入力できる場合があります。 このルールについて詳しくは、「ルールセットで使用できるルール」をご覧ください。

注: [その他の設定] セクションで [マージ前に状態チェックを必須にする] をオンにする場合:

  • 必須にする各状態チェックの名前を入力できます。 要件としての状態チェックの追加を完了するには、 をクリックする必要があります。
  • [マージする前にブランチを最新にする必要がある] をオンにする場合は、保護を有効にするためのチェックを定義する必要があります。

メタデータの制限追加

注:

  • メタデータの制限を追加すると、リポジトリに投稿しているユーザーのエクスペリエンスに影響を及ぼす可能性があります。 メタデータ制限を含むルールセットを適用する前に、ルールセットに対して "評価" の適用状態を選択し、共同作成者に影響を与えることなくメタデータ制限の効果をテストすることができます。 メタデータの制限について詳しくは、「ルールセットで使用できるルール」をご覧ください。
  • メタデータの制限は、リポジトリでのコミット間の整合性の向上を目的としています。 pull request でのコード レビュー必須化などのセキュリティ対策を置き換えることを意図したものではありません。
  • ブランチをスカッシュ マージする場合、そのブランチに対するすべてのコミットは、ベース ブランチのメタデータ要件を満たす必要があります。

  1. 必要に応じて、[メタデータの制限] セクションで、ブランチまたはタグにプッシュされているコミットのメタデータを制御するルールを追加するには、 をクリックします。

    [メタデータの制限] セクションのスクリーンショット。 ヘッダーの右側にあるプラスアイコンがオレンジ色の枠線で強調表示されています。

  2. メタデータの制限ルールの設定を構成して、[追加] をクリックします。 同じルールセットに複数の制限を追加できます。

    [一致するパターンで開始する必要がある] など、ほとんどの要件では、入力したパターンはリテラルに解釈され、ワイルドカードはサポートされません。 たとえば、* 文字が表すのは、リテラルな * 文字のみです。

    より複雑なパターンの場合は、[特定の正規表現パターンに一致する必要がある] または [特定の正規表現パターンに一致しない] を選び、正規表現構文を使って、一致するパターンを定義できます。 詳しくは、「メタデータのコミットに正規表現を使う」をご覧ください。

    リポジトリのルールセットを表示しているすべてのユーザーは、指定した説明を表示できます。

ルールセットの最終処理と次の手順

ルールセットの作成を完了するには、[作成] をクリックします。 ルールセットの適用ステータスが "アクティブ" に設定されている場合、ルールセットはすぐに有効になります。

ルールセットの分析情報を表示して、ルールが共同作成者にどのように影響しているかを確認できます。 適用ステータスが "評価" に設定されている場合、ルール セットがアクティブであった場合に合格または失敗したアクションを確認できます。 ルールセットの分析情報の詳細については、、「リポジトリのルールセットの管理」を参照してください。

ブランチ、タグ、リポジトリの fnmatch パターンについて

fnmatch 構文を使うと、ルールセットを作成するときに、ブランチ、タグ、リポジトリの名前をターゲットにするパターンを定義できます。

* ワイルドカードを使って、任意の文字列に一致させることができます。 GitHub では File::FNM_PATHNAME フラグを File.fnmatch 構文で使うため、* のワイルドカードがディレクトリの区切り記号 (/) と照合されません。 たとえば、qa/* は、qa/ で始まり、1 つのスラッシュを含むすべてのブランチと照合されますが、qa/foo/bar とは照合されません。 qa の後には、qa/**/* を使用して任意の数のスラッシュを含めることができます。これは、たとえば qa/foo/bar/foobar/hello-world と一致します。 qa**/**/* を使い qa の文字列を拡張して、より包括的にすることもできます。

構文のオプションについて詳しくは、fnmatch のドキュメントを参照してください。

注: GitHub は fnmatch 構文で File::FNM_PATHNAME はサポートされていますが、File::FNM_EXTGLOB はサポートされていません。

コミット メタデータ用正規表現について

メタデータの制限を追加するときは、正規表現構文を使って、関連するメタデータ (コミット メッセージ、ブランチ名、タグ名など) が一致する必要のある、または一致してはならないパターンを定義できます。

ルールセットでは、RE2 構文がサポートされています。 詳しくは、Google の構文ガイドに関するページをご覧ください。 式を検証するには、regex101.com の検証コントロールを使い、左側のサイドバーで "Golang" フレーバーを選択できます。

既定では、メタデータ制限の正規表現では、複数行のテキストは考慮されません。 たとえば、複数行のコミット メッセージがある場合、パターン ^ABC は、メッセージの最初の行が ABC で始まっていれば一致します。 複数行のメッセージと一致させるには、表現を (?m) で開始します。

?! で示される負の先読みアサーションはサポートされていません。 ただし、特定の文字列の後に別の特定の文字列が続いていないケースを検索する必要がある場合は、? で示される正の先読みアサーションを、"特定の正規表現パターンと一致してはならない" という要件と組み合わせて使用できます。

注: 共同作成者にコミットのサインオフを要求する場合は、それが正規表現のパターンを妨げる可能性があります。 ユーザーがサインオフすると、GitHub によって Signed-off-by: #AUTHOR-NAME <#AUTHOR-EMAIL> のような文字列がコミット メッセージに追加されます。 詳しくは、「Organization のコミット サインオフ ポリシーの管理」を参照してください。

便利な正規表現パターン

次の例では、コミット メタデータに役立つパターンを示します。 これらのパターンを使用するには、 [要件] を [特定の正規表現パターンに一致する必要がある] に設定します。

ブランチ名が Windows と互換性があることを確認する

次のパターンを使って、ブランチ名に数字、小文字、文字 - と _ のみが含まれることを確認できます。 これにより、ブランチ名が、既定で大文字と小文字を区別するファイル システムを使用しないオペレーティング システムと互換性があることが確認されます。

Text
\A[0-9a-z-_]$

一致する: my-branch

一致しない: myBranch

タグ名でセマンティック バージョン管理が使用されていることを確認する

次のパターンを使って、タグ名がセマンティック バージョン管理に準拠していることを確認できます。 詳しくは、semver.org のドキュメントをご覧ください。

Text
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

一致する: 1.2.3、10.20.30、1.1.2-prerelease+meta

一致しない: 1.2、1.2-SNAPSHOT

コミット メッセージの行の長さを制限する

Pro Git の書籍では、コミット メッセージの最初の行を約 50 文字に制限することが推奨されています。

次のパターンを使って、コミット メッセージの最初の行が 50 文字以下であることを確認できます。

Text
\A.{1,50}$
コミット メッセージが解決と issue 番号で始まっていることを確認する

次のパターンを使って、コミット メッセージに Resolves: または Fixes: という単語と、それに続く #1234 のような文字列が含まれていることを確認できます。

Text
^(Resolves|Fixes): \#[0-9]+$

一致する: Fixes: #1234

一致しない: Add conditional logic to foo.bar

従来のコミットを適用する

次のパターンを使って、コミット メッセージが従来のコミット仕様に準拠していることを確認できます。 詳しくは、conventionalcommits.org をご覧ください。

Text
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)

一致する: feat: allow provided config object to extend other configs

一致しない: Add conditional logic to foo.bar