ルールセットで使用できるルール

ユーザーがリポジトリ内で選択したブランチとタグを操作する方法を制御するために、ブランチまたはタグのルールセットを作成することができます。 また、プッシュ ルールセットを作成し、プライベート リポジトリまたは内部リポジトリと、そのリポジトリのフォーク ネットワーク全体へのプッシュをブロックすることもできます。

ルールセットを作成するときに、特定のユーザーがルールセットの中のルールをバイパスすることを許可できます。 これは、特定のロールを持つユーザー、特定のチーム、または GitHub Apps にすることができます。

プッシュ ルールセットの場合、バイパス アクセス許可は、リポジトリとリポジトリのフォーク ネットワーク全体に適用されます。 つまり、このリポジトリのフォーク ネットワーク全体のリポジトリでこのルールセットをバイパスできる唯一のユーザーが、ルート リポジトリでこのルールセットをバイパスできるユーザーです。

ルールセットとバイパス アクセス許可の作成の詳細については、「組織内のリポジトリのルールセットを作成する」と「リポジトリのルールセットの作成」を参照してください。

作成を制限する

これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグを作成できます。

更新を制限する

これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグにプッシュできます。

削除を制限する

これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグを削除できます。 このルールは既定で選ばれています。

連続的な履歴を要求する

直線状のコミット履歴を強制すると、コラボレーターがターゲットとするブランチにマージ コミットをプッシュすることを防げます。 つまり、ブランチまたはタグにマージされる pull request は、スカッシュ マージまたはリベース マージを使用する必要があります。 厳格な直線状のコミット履歴は、Team が変更をより簡単に元に戻すために役立ちます。 マージ方法の詳細については、「プルリクエストのマージについて」を参照してください。

直線状のコミット履歴をリクエストする前に、リポジトリで squash マージまたはリベースマージを許可する必要があります。 詳しくは、「プルリクエストのマージ設定を行う」をご覧ください。

[Require merge queue](マージ キュー必須)

マージを実行するために、リポジトリ レベルでのマージ キューの使用を必須とすることができます。 マージ キューの詳細については、「pull request とマージ キューのマージ」を参照してください。

追加設定

マージ キュー ルールに対して、さまざまな設定を構成することができます。

•         **マージ方法:** pull request (プル リクエスト) からの変更をマージするときに使用する方法。
  

•         **ビルドのコンカレンシー:** チェックとワークフローの実行を要求する pull request (プル リクエスト) が同時にキューに登録される個数を制限します。
  

  • この設定は、マージ キューが merge_group.checks_requested Webhook イベントをディスパッチするタイミングを制御します。このイベントは、merge_group で実行されるように構成された GitHub Actions ワークフローをトリガーします。 詳しくは、「Webhook のイベントとペイロード」をご覧ください。
  • たとえば、5 個の pull request (プル リクエスト) がキューに追加されていて、ビルドのコンカレンシー設定が 3、マージ キューは最初の 3 個の pull request の checks_requested イベントをディスパッチします。 これらの pull request (プル リクエスト) のいずれか 1 件の結果を受け取ると、マージ キューは 4 番目の pull request のイベントをディスパッチし、以下同様になります。

•         **Minimum/maximum group size: (最小/最大グループ サイズ:)** 1 個のグループにマージされる pull request (プル リクエスト) の数。
  

•         **Wait time to meet minimum group size (minutes): (最小グループ サイズを満たすまでの待機時間 (分):)** 最初の pull request (プル リクエスト) がキューに追加された後、最小グループ サイズが満たされるまで、マージ キューが待機する時間。 この時間が経過した後、最小グループ サイズは無視され、それより小さいグループにマージされます。
  

•         **Require all queue entries to pass required checks: (すべてのキュー エントリが必要なチェックに合格することが必須:)**
  

  • この設定を有効にすると、マージ グループ内の各アイテムが必要なすべてのチェックに合格する必要があります。
  • この設定を無効にすると、マージ グループの先頭にあるコミット (つまり、グループ内のすべての pull request (プル リクエスト) からの変更を含むコミット) のみが、マージに必要なチェックに合格する必要があります。

•         **Status check timeout (minutes): (ステータス チェックのタイムアウト (分):)** 結論を報告するために必要なステータス チェックの最大時間。 この時間が経過した後、結論を報告していないチェックは不合格と見なされます
  

マージ前に展開の成功が必要

ブランチをマージする前に、変更が特定の環境に正常にデプロイされる必要があるように設定できます。 たとえば、この規則を使用し、変更がステージング環境に正常にデプロイされた後で、変更を既定のブランチにマージされるようにすることができます。

署名付きコミットを要求する

コミット署名の必須化をブランチで有効にすると、共同作成者とボットは、署名されて検証されたコミットのみをブランチにプッシュできます。 詳しくは、「コミット署名の検証について」をご覧ください。

ブランチ保護ルールとルールセットは、ブランチを作成するときの動作が異なります。ルールセットを使用する場合は、他のブランチからアクセスできないコミットのみをチェックします。一方、ブランチ保護ルールを使用する場合は、一致するブランチを作成するプッシュを制限しない限り、署名済みのコミットをチェックしません。 どちらを使用する場合も、ブランチを更新すると、他のブランチからコミットに到達できる状況であっても、指定された範囲内にあるすべてのコミットをチェックします。

どちらの方法でも、verified_signature? を使用してコミットに有効な署名があるかどうかを確認します。 それ以外の場合、更新は受け入れられません。

コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 pull request (プル リクエスト) を使用し、署名済みかつ検証済みのコミットをブランチにマージすることもできます。 ただし、pull request (プル リクエスト) の作成者でない限り、pull request をスカッシュして GitHub のブランチにマージすることはできません。pull request をローカルでスカッシュおよびマージできます。 詳しくは、「プルリクエストをローカルでチェック アウトする」をご覧ください。

マージ方法の詳細については、「GitHubのマージ メソッドについて」を参照してください。

マージ前に pull request を要求する

ターゲット ブランチに対するすべての変更を pull request に関連付ける必要があるように設定できます。 pull request を必ずしも承認する必要はありませんが、開く必要があります。

追加設定

リポジトリ管理者または "リポジトリ ルールの編集" アクセス許可を持つカスタム ロールは、すべての pull request について、ユーザーが pull request を保護されたブランチにマージするには、その前に特定の数のレビュー承認を受け取る必要があるようにすることができます。 リポジトリに書き込み権限を持っている人か、指定されたコードオーナーからの承認レビューを必須とすることができます。

必須レビューを有効にした場合、コラボレーターは、書き込み権限を持つ必要な人数のレビュー担当者により承認された pull request からしか、ブランチに変更をプッシュできなくなります。

誰かがレビューで [変更の要求] オプションを選んだ場合、pull request をマージするためには、その誰かが pull request を承認する必要があります。 プルリクエストへの変更をリクエストしたレビュー担当者の手が空いていない場合、そのリポジトリに書き込み権限を持つ人が、ブロックしているレビューを却下できます。

すべての必須のレビュー担当者がPull Requestを承認した後でも、同じコミットを指すヘッドブランチを持つ、保留中もしくは拒否されたレビューを持つオープンなPull Requestが他にある場合、コラボレータはそのPull Requestをマージできません。 まず、他のPull Request上のブロックしているレビューを、書き込み権限を持つ誰かが承認もしくは却下しなければなりません。

必要に応じて、pull request の diff に影響するコミットがプッシュされたときに古い pull request の承認を無視することを選べます。 GitHub によって、pull request が承認された時点での差分の状態が記録されます。 この状態は、レビュー担当者が承認した一連の変更を表します。 この状態から diff が (たとえば、共同作成者が pull request ブランチに新しい変更をプッシュしたか、[ブランチを更新] をクリックしたため、または関連する pull request がターゲット ブランチにマージされたために) 変更された場合、承認レビューは古いものとして無視され、誰かが作業をもう一度承認するまで pull request をマージすることはできません。 ターゲット ブランチの詳細については、「pull requests について」を参照してください。

必要に応じて、コードオーナー'からのレビューを必須にすることもできます。 そうした場合、コード オーナーが存在するコンテンツに変更を加える pull request は、保護されたブランチに pull request をマージする前に、そのコード オーナーから承認される必要があります。 コードに複数の所有者が存在する場合、この要件を満たすには、_いずれか_のコード所有者からの承認で十分であることに注意してください。 詳しくは、「コードオーナーについて」をご覧ください。

必要に応じて、pull request (プル リクエスト) をマージする前に、最後のユーザー以外のユーザーがブランチへのプッシュを承認することを要求できます。 これは、少なくとももう 1 人の許可されたレビュー担当者が変更を承認済みであることを意味します。 たとえば、"最後のレビュー担当者" は、最新の一連の変更に、他のレビューからのフィードバックが組み込まれていて、未レビューの新しいコンテンツが追加されていないことを確認できます。

多くのレビューを必要とする複雑な pull request、妥協策として、最後にプッシュしたユーザー以外のユーザーによる承認を必須にすると、すべての古いレビューを無視する必要がなくなります。このオプションを使うと、"古い" レビューは無視されず、最新の変更を行ったユーザー以外のユーザーがそれを承認している限り、pull request は承認済みのままになります。 pull request を既にレビューしているユーザーは、最後のプッシュの後でもう一度承認して、この要件を満たすことができます。 pull request が "ハイジャックされる" (承認された pull request に未承認のコンテンツが追加される) 懸念がある場合は、古いレビューを無視する方が安全です。

必要に応じて、pull request をブランチにマージする前に、関連するすべてのコメントを解決する必要があるように設定できます。 これにより、マージ前にすべてのコメントが対処または確認されます。

必要に応じて、マージの種類としてマージ、スカッシュ、リベースのいずれかを要求できます。 これは、許可された種類に基づいている場合のみ、ターゲットのブランチをマージできることを意味します。 さらに、リポジトリであるマージ方法が無効になっており、ルールセットで別の方法が必須になっている場合、マージはブロックされます。 「GitHubのマージ メソッドについて」を参照してください。

必要なレビュー担当者

必要に応じて、プル要求によって特定のファイルまたはディレクトリが変更されたときに、特定のチームからのレビューまたは承認を要求できます。 最大 15 個の異なるチームを指定できます。チームごとに、チーム メンバーから一定数の承認を要求できます。

          **[レビュー担当者]** ドロップダウンでは、ルールが定義されているスコープ内の任意のチームを選択できます。 

* 組織全体のルール: チームは組織に属している必要があります。 * リポジトリ レベルのルール: チームは、リポジトリを所有する組織に属している必要があります。

このルールは、チームが含まれていないため、ユーザー所有のリポジトリでは使用できません。

必要な承認は、0 (ゼロ) から 10 に設定できます。 承認をゼロにすることは、チームが可視性のために追加されることを意味しますが、チームは要求を承認する必要はありません。

チームごとに、設定が適用されるファイルを決定するファイル パターンの一覧を指定できます。 このファイル リストの形式は、標準の .gitignore ファイルと同じです。

• 感嘆符 (!) で始まるパターンは否定です。 これにより、以前のパターンに一致するパスは承認を必要 としません 。
• パターンは順番に一致するため、否定されたパターンでは、前の規則に一致したファイルが "一致しない" 可能性があります。

マージに合格するには状態チェックを必須にする

必須ステータス チェックにより、コラボレーターがルールセットの適用対象であるブランチまたはタグに変更を加える前に、すべての必須 CI テストにパスしていることが保証されます。 必須の状態チェックは、チェックまたはステータスにすることができます。 詳しくは、「ステータスチェックについて」をご覧ください。

コミット ステータス API を使用して、外部サービスが適切な状態のコミットにマークを付けることを許可できます。 詳しくは、「コミットのステータス用の REST API エンドポイント」をご覧ください。

ステータス チェック必須を有効にした場合、すべての必須ステータス チェックにパスしないと、コラボレーターはブランチまたはタグに変更をマージできません。 必要に応じて、ステータス チェックの結果に関係なくブランチの作成を許可する場合は、[Do not require status checks on creation (作成時にステータス チェックを必要としない)] を選択できます。

リポジトリへの書き込み権限があるユーザーまたは統合は、リポジトリのステータス チェックを任意の状態に設定できますが、場合によっては特定の GitHub App のステータス チェックのみを受け入れる必要があります。 ステータス チェックが必須というルールを追加するときに、ステータス更新のソース (情報源) として想定されるアプリを選択できます。 そのアプリは、statuses:write アクセス許可のあるリポジトリにインストールされている必要があり、最近チェック実行を送信した必要があります。また、ルールセットの既存の必須スタータス チェックに関連付けられている必要があります。 状態が他のユーザーまたは統合によって設定されている場合、マージは許可されません。 [any source (任意のソース)] を選択した場合は、マージ ボックスに一覧表示されている各状態の作成者を引き続き手動で確認することができます。

ルールセット内でステータス チェックの構成に関する問題が発生したときのトラブルシューティングについては、「トラブルシューティングルール」を参照してください。

必須ステータス チェックは、"緩い" または "厳格" のいずれかであると考えることができます。 選択した必須ステータスチェックのタイプにより、マージする前にブランチをベースブランチとともに最新にする必要があるかどうかが決まります。

必須ステータスチェックのタイプ	設定	マージの要件	考慮事項

          **Strict** | 
          **[Require branches to be up to date before merging](マージ前にブランチの最新状態必須)** チェックボックスをオンにします。 | トピック ブランチは、マージ前にベース ブランチと同じ最新状態である**必要があります**。 | これは、必須ステータスチェックのデフォルト動作です。 他のコラボレーターがターゲット ブランチを更新したら、head ブランチを最新の状態にする必要があるため、追加のビルドが必要になる場合があります。|

| [Loose (寛容)] | Require branches to be up to date before merging チェックボックスをオンにしません。 | ブランチは、マージ前にベース ブランチと同じ最新状態である必要はありません。 | 他のコラボレーターがプルリクエストをマージした後に head ブランチをアップデートする必要はないことから、必要となるビルドは少なくなります。 base ブランチと競合する変更がある場合、ブランチをマージした後のステータスチェックは失敗する可能性があります。 | | Disabled | Require status checks to pass before merging チェックボックスをオンにしません。 | ブランチのマージについての制限はない | 必須ステータスチェックが有効化されていない場合、base ブランチにあわせてアップデートされているかどうかに関わらず、コラボレーターはいつでもブランチをマージできます。 このことで、変更の競合が発生する可能性が高まります。

ステータス チェックのトラブルシューティング情報については、「必須ステータスチェックのトラブルシューティング」を参照してください。

強制プッシュのブロック

ユーザーがターゲットのブランチまたはタグに強制的にプッシュできないようにすることができます。 このルールは既定で有効になっています。

誰かがブランチまたはタグに強制的にプッシュした場合、他のコラボレーターが各自の作業のベースにしたコミットが、ブランチまたはタグの履歴から削除される可能性があります。 これにより、マージの競合や pull request の破損が発生する可能性があります。 強制プッシュを使用すると、pull request でブランチが削除されたり、承認されていないコミットがブランチでポイントされたりする可能性もあります。

強制プッシュを有効にしても、他のルールはオーバーライドされません。 たとえば、ブランチに直線状のコミット履歴が必要な場合、そのブランチにマージコミットをフォースプッシュすることはできません。

code scanning の結果が必要です

リポジトリが code scanning を使用して構成されている場合は、ルールセットを使用して、次のいずれかの条件が満たされたときに pull request (プル リクエスト) がマージされることを防止できます。

• 必要なツールは、ルール セットで定義されている重大度の code scanning アラートを検索します。
• 必要なツールの分析はまだ進行中です。
• リポジトリに必要なツールが構成されていません。

詳しくは、「コード スキャンのマージ保護を設定します」をご覧ください。 code scanning の一般的な情報:については、「AUTOTITLE」を参照してください。

コード品質の結果を要求する

リポジトリが GitHub Code Quality で構成されている場合は、ルールセットを使用して、次のいずれかの条件が満たされたときにプル要求がマージされないようにすることができます。

• 分析はまだ進行中です。
• 分析はさまざまな理由で失敗することがあります。たとえば、アクション分の時間の予算を使い果たした場合です。
• Code Quality は、ルールセット内で定義された重大度レベルまたはそれ以上の重大度を持つ結果を検出しました。

詳細については、「GitHubのコード品質について」および「プル要求のコード品質しきい値の設定」を参照してください。

マージ前にワークフローの合格を必須にする

Pull request をマージする前にワークフローの通過を必須にするように、organization または Enterprise レベルでルールセット ワークフローを構成できます。 詳しくは、「組織内のリポジトリのルールセットを作成する」をご覧ください。

一般的なルールセット ワークフローの構成設定のトラブルシューティングの詳細については、「トラブルシューティングルール」を参照してください。

ワークフロー ファイルの使用

このルールを使用するには、最初にワークフロー ファイルを作成する必要があります。 ワークフロー ファイルは、そのファイルの実行に使用するリポジトリと、同じ可視性を持つリポジトリに置く必要があります。 具体的には、パブリック ワークフローは組織内の任意のリポジトリで実行でき、内部ワークフローは内部リポジトリとプライベート リポジトリでのみ実行でき、プライベート ワークフローはプライベート リポジトリでのみ実行できます。 詳しくは、「ワークフロー」をご覧ください。

ワークフロー ファイルが内部リポジトリまたはプライベート リポジトリ内に存在し、組織内の他のリポジトリでそのワークフローを使用することを希望する場合は、リポジトリの外部からそのワークフローにアクセスできるようにする必要があります。 詳細については、「内部リポジトリ内のコンポーネントへのアクセスを許可する」または「プライベート リポジトリ内のコンポーネントへのアクセスを許可する」を参照してください。

このルールをルールセットに追加する際には、organization (組織) の設定で、ソース リポジトリと、適用しようとするワークフローを選択します。

ルールセット ワークフローで [評価] モードを使用する

ルールセット ワークフローを [評価] モードで実行し、合格した場合は、ルールセット ワークフローを [アクティブ] モードに設定し、新しいワークフロー実行をトリガーせずに pull request (プル リクエスト) を統合することができます。

[評価] モードでルールセットを作成する前に pull request (プル リクエスト) を開くと、ルールセットが適用されないため、引き続きその pull request を統合できます。

適用ステータスの詳細については、「リポジトリのルールセットの作成」を参照してください。

サポートされているイベント トリガー

ルールセット ワークフローでは、pull_request、pull_request_target および merge_group イベントの使用がサポートされます。 その結果、ワークフローがルールセットによって実行されるように、ワークフローの on: セクションで、これらのイベントのうち 1 個以上を指定する必要があります。

サポートされているイベントに対して指定したフィルターは無視されます - 例: branches、 branches-ignore、 paths など types。 ワークフローは、サポートされているイベントの既定のアクティビティの種類によってのみトリガーされ、すると常に作動します。

Event	既定のアクティビティの種類
pull_request	opened、synchronize、reopened
pull_request_target	opened、synchronize、reopened
merge_group	checks_requested

ルールセット ワークフローを使用した特定のブランチのターゲット設定

このルールを適用すると、ダイレクト プッシュがブロックされます。ルールセット ワークフローは、 pull request (プル リクエスト) およびマージ キュー エクスペリエンスの一部として実行されるからです。 この理由で、リポジトリ内にあるすべてのブランチを対象とするルールセットに、このルールを適用しないでください。

このルールの追加先として使用できるのは、ブランチに対するすべての変更を pull request (プル リクエスト) で実行するブランチをターゲットとするルールセットのみです。

必要に応じて、ステータス チェックの結果に関係なくブランチの作成を許可する場合は、[Do not require status checks on creation (作成時にワークフロー チェックを必要としない)] を選択できます。

メタデータの制限

GitHub Enterprise プランを利用している Organization は、コミット メタデータの書式を制御する追加のルールにアクセスできます。 リテラル文字列または正規表現構文を使用して、コミット メタデータが準拠する必要があるパターンを定義できます。 たとえば、コミット メッセージに GitHub の issue 番号が含まれていることや、コミッターまたは作者が @octoorg.com で終わるメール アドレスを持っていることを必須にすることができます。 新しいブランチ名とタグ名の形式を制御することもできます。 コミット メタデータに役立つ正規表現の選択肢については、「リポジトリのルールセットの作成」を参照してください。

コントリビューターが要件を満たしていないコミットでブランチまたはタグを更新しようとすると、コントリビューターにコミットの何が問題かを示すエラーが表示されます。 このエラーは、コマンド ライン (ユーザーがプッシュするとき) と GitHub.com (ユーザーが pull request をコミットまたはマージしようとしたとき) の両方に表示される可能性があります。 Git ではコミットは変更不可です。コントリビューターは、コミットを作成した後はコミットのメタデータを編集できないため、リポジトリに作業を正常に投稿する前に、コミット履歴を新しいコミットで書き換えるためにリベースを実行することが必要な場合があります。

メタデータ制限は、ブランチの履歴におけるコミット間の整合性を強制する場合に役立ちます。 これは、従来のコミットの仕様などのベスト プラクティスへの準拠を強制する場合や、コミット メタデータに依存するツールとの統合に役立ちます。 たとえば、各メッセージが予測可能な形式に準拠していれば、コミット メッセージの内容に基づいてスクリプトを実行することが簡単になります。

メタデータ制限に関する重要な考慮事項

メタデータ制限では、"ref updates" がブロックされます。 コントリビューターが要件を満たしていないコミットを含む作業をプッシュした場合、プッシュは拒否されませんが、ターゲットとするブランチまたはタグは更新されません。 技術的には、その場合でもコミットはリポジトリに反映されます。コミットは "取得可能" (リポジトリ内でそこに移動できる) になりますが、"到達可能" ではありません (ブランチまたはタグの履歴に接続されません)。 共同作成者のプッシュに、それらのブランチまたはタグの要件を満たすコミットを含む他のブランチまたはタグに対する作業も含まれている場合、それらの参照は正常に更新されます。

メタデータ制限により、リポジトリへのコントリビューションを行うユーザーにとっては、摩擦が増える可能性があります。 一般に、メタデータ制限を適用する場合は、共同作成者の日常の作業に影響を与えないように、限られたブランチ セットに対して行う必要があります。 たとえば、共同作成者が作業する可能性のあるトピック ブランチで、一貫性のあるコミット メッセージを必須とする代わりに、main でのみ一貫性のあるコミット メッセージを必須にし、その後、main への pull request (プル リクエスト) を必須にする必要があります。

スカッシュ マージを使用する場合、pull request (プル リクエスト) 内の個々のコミットは無視されます。 代わりに、結果として得られた単一のマージ コミットのメタデータに対してのみ、制限が検証されます。 pull request (プル リクエスト) ページでは、マージが許可される前にこの情報が検証されるので、最終的なコミットは確実に準拠したものになります。 コミッター メールに適用されるメタデータ制限の場合、制限を満たすためのスカッシュ マージに対応する noreply@github.com も、パターンに含める必要があります。

既存のブランチまたはタグにメタデータ制限を追加すると、その時点から以降にブランチまたはタグにプッシュされた新しいコミットに対してルールが適用されますが、ブランチまたはタグの既存の履歴に対しては適用されません。

ファイル パスを制限する

指定したファイル パスの中に変更を含めているコミットが、リポジトリにプッシュされることを防止します。 上限は 200 エントリ、なおかつ各エントリは最大 200 文字です。

これには fnmatch の構文を使用できます。 たとえば、test/demo/**/* を対象とする制限により、test/demo/ ディレクトリ内のファイルまたはフォルダーへのプッシュが禁止されます。 test/docs/pushrules.md を対象とした制限により、test/docs/ ディレクトリ内の pushrules.md ファイルへのプッシュが禁止されます。 詳しくは、「リポジトリのルールセットの作成」をご覧ください。

ファイル パスの長さを制限する

指定した文字制限を超過するファイル パスを含むコミットが、リポジトリにプッシュされることを防止します。

ファイル拡張子を制限する

指定したファイル拡張子を持つファイルを含むコミットが、リポジトリにプッシュされることを防止します。 上限は 200 エントリ、なおかつ各エントリは最大 200 文字です。

ファイル サイズを制限する

指定したファイル サイズ制限を超過するコミットが、リポジトリにプッシュされることを防止します。