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

リポジトリ内の特定のブランチとタグを保護するためにルールセットに追加できるルールについて説明します。

この機能を使用できるユーザーについて

リポジトリのルールセットは、そのリポジトリの読み取りアクセス権を持つすべてのユーザーが表示できます。リポジトリの管理者アクセス権を持つユーザー、または "リポジトリルールの編集" アクセス許可のあるカスタムロールは、リポジトリのルールセットを作成、編集、削除できます。

ルールセットは、GitHub Free と GitHub Free の Organization のパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud のパブリックとプライベートのリポジトリで利用できます。詳細については、「GitHubのプラン」を参照してください。

プッシュルールセットは、内部リポジトリとプライベートリポジトリの GitHub Team プランと、プッシュルールセットが有効になっているリポジトリのフォークで使用できます。

この記事で

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

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

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

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

作成を制限する

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

更新を制限する

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

削除を制限する

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

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

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

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

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

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

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

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

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

メモ

アカウント設定で警戒モード (コミットが常に署名される) を有効にした場合、GitHub によって "部分的に検証済み" と識別されたすべてのコミットは、署名付きコミットが必須であるブランチで許可されます。警戒モードの詳細については、「すべてのコミットの検証ステータスを表示する」を参照してください。
コラボレーターが未署名のコミットを、コミット署名必須のブランチにプッシュする場合、コラボレーターは検証済み署名を含めるためにコミットをリベースしてから、書き直したコミットをブランチにフォースプッシュする必要があります。

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

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

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

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

追加設定

メモ

[新たなコミットがプッシュされたときに古い pull request の承認を却下する] や [最新のレビュー可能なプッシュの承認を要求する] を選んだ場合、マージの内容が 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 の 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 エンドポイント」をご覧ください。

ステータスチェック必須を有効にした場合、すべての必須ステータスチェックにパスしないと、コラボレーターはブランチまたはタグに変更をマージできません。

リポジトリへの書き込み権限があるユーザーまたは統合は、リポジトリのステータスチェックを任意の状態に設定できますが、場合によっては特定の 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のコード品質について」および「プル要求のコード品質しきい値の設定」を参照してください。