ユーザーがリポジトリ内で選択したブランチとタグを操作する方法を制御するために、ブランチまたはタグのルールセットを作成することができます。 また、プッシュ ルールセットを作成して、プライベート リポジトリまたは内部リポジトリとそのリポジトリのフォーク ネットワーク全体へのプッシュをブロックすることもできます。
ルールセットを作成するときに、特定のユーザーがルールセットの中のルールをバイパスすることを許可できます。 これは、特定のロール、特定のチーム、または GitHub Appsを持つユーザーです。
プッシュ ルールセットの場合、バイパス アクセス許可は、リポジトリとリポジトリのフォーク ネットワーク全体に適用されます。 つまり、このリポジトリのフォーク ネットワーク全体のリポジトリでこのルールセットをバイパスできる唯一のユーザーが、ルート リポジトリでこのルールセットをバイパスできるユーザーです。
ルールセットの作成とアクセス許可のバイパスの詳細については、「 リポジトリのルールセットの作成」を参照してください。
作成を制限する
これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグを作成できます。
更新を制限する
これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグにプッシュできます。
削除を制限する
これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグを削除できます。 このルールは既定で選ばれています。
連続的な履歴を要求する
直線状のコミット履歴を強制すると、コラボレーターがターゲットとするブランチにマージ コミットをプッシュすることを防げます。 つまり、ブランチまたはタグにマージされる pull request は、スカッシュ マージまたはリベース マージを使用する必要があります。 厳格な直線状のコミット履歴は、Team が変更をより簡単に元に戻すために役立ちます。 マージ方法の詳細については、「プル要求のマージ」を参照してください。
直線状のコミット履歴をリクエストする前に、リポジトリで squash マージまたはリベースマージを許可する必要があります。 詳しくは、「プルリクエストのマージ設定を行う」をご覧ください。
マージ前に展開の成功が必要
ブランチをマージする前に、変更が特定の環境に正常にデプロイされる必要があるように設定できます。 たとえば、この規則を使用し、変更がステージング環境に正常にデプロイされた後で、変更を既定のブランチにマージされるようにすることができます。
署名付きコミットを要求する
ブランチで必要なコミット署名を有効にすると、共同作成者 ボット は、署名されて検証されたコミットのみをブランチにプッシュできます。 詳しくは、「コミット署名の検証について」をご覧ください。
ブランチ保護ルールとルールセットは、ブランチを作成するときの動作が異なります。ルールセットを使用する場合は、他のブランチからアクセスできないコミットのみをチェックします。一方、ブランチ保護ルールを使用する場合は、一致するブランチを作成するプッシュを制限しない限り、署名済みのコミットをチェックしません。 どちらを使用する場合も、ブランチを更新すると、他のブランチからコミットに到達できる状況であっても、指定された範囲内にあるすべてのコミットをチェックします。
どちらの方法でも、verified_signature? を使用してコミットに有効な署名があるかどうかを確認します。 それ以外の場合、更新は受け入れられません。
メモ
- コミットが常に署名されることを示す、アカウント設定で監視モードを有効にした場合、 GitHub が "部分的に検証済み" と識別するコミットは、署名されたコミットを必要とするブランチで許可されます。 警戒モードの詳細については、「すべてのコミットの検証ステータスを表示する」を参照してください。
- コラボレーターが未署名のコミットを、コミット署名必須のブランチにプッシュする場合、コラボレーターは検証済み署名を含めるためにコミットをリベースしてから、書き直したコミットをブランチにフォース プッシュする必要があります。
コミットが署名されて検証された場合は、ローカル コミットをブランチにプッシュできます。
pull request を使用して、署名済みコミットと検証済みコミットをブランチにマージすることもできます。 GitHub は、プルリクエストをマージできるかどうかを評価する際に、親コミットがベースブランチの最新コミットとプルリクエストのヘッドコミットであるテストマージコミットを作成します。 GitHub は、ヘッド ブランチからのコミットを含め、このテスト マージによって導入されたコミットをチェックします。 その結果、HEAD ブランチ上の未署名のコミットによって、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 は、プル要求が承認された時点での差分の状態を記録します。 この状態は、レビュー担当者が承認した一連の変更を表します。 この状態から diff が (たとえば、共同作成者が pull request ブランチに新しい変更をプッシュしたか、[ブランチを更新] をクリックしたため、または関連する pull request がターゲット ブランチにマージされたために) 変更された場合、承認レビューは古いものとして無視され、誰かが作業をもう一度承認するまで pull request をマージすることはできません。 ターゲット ブランチの詳細については、「Pull Request」を参照してください。
必要に応じて、コードオーナー'からのレビューを必須にすることもできます。 そうした場合、コード オーナーが存在するコンテンツに変更を加える pull request は、保護されたブランチに pull request をマージする前に、そのコード オーナーから承認される必要があります。 コードに複数の所有者が存在する場合、この要件を満たすには、_いずれか_のコード所有者からの承認で十分であることに注意してください。 詳しくは、「コードオーナーについて」をご覧ください。
必要に応じて、pull request レビューを無視できるユーザーを制限できます。 この設定を有効にした場合は、ルールセットの対象となるブランチのレビューを無視できるユーザー、チーム、または GitHub Apps を選択します。 この設定は、UI または REST API または GraphQL API を使用して構成できます。 詳しくは、「プルリクエストレビューの却下」をご覧ください。
必要に応じて、pull request (プル リクエスト) をマージする前に、最後のユーザー以外のユーザーがブランチへのプッシュを承認することを要求できます。 これは、少なくとももう 1 人の許可されたレビュー担当者が変更を承認済みであることを意味します。 たとえば、"最後のレビュー担当者" は、最新の一連の変更に、他のレビューからのフィードバックが組み込まれていて、未レビューの新しいコンテンツが追加されていないことを確認できます。
多くのレビューを必要とする複雑な pull request、妥協策として、最後にプッシュしたユーザー以外のユーザーによる承認を必須にすると、すべての古いレビューを無視する必要がなくなります。このオプションを使うと、"古い" レビューは無視されず、最新の変更を行ったユーザー以外のユーザーがそれを承認している限り、pull request は承認済みのままになります。 pull request を既にレビューしているユーザーは、最後のプッシュの後でもう一度承認して、この要件を満たすことができます。 pull request が "ハイジャックされる" (承認された pull request に未承認のコンテンツが追加される) 懸念がある場合は、古いレビューを無視する方が安全です。
必要に応じて、pull request をブランチにマージする前に、関連するすべてのコメントを解決する必要があるように設定できます。 これにより、マージ前にすべてのコメントが対処または確認されます。
必要に応じて、マージ、スカッシュ、またはリベースのマージの種類を要求できます。 これは、許可された種類に基づいている場合のみ、ターゲットのブランチをマージできることを意味します。 さらに、リポジトリであるマージ方法が無効になっており、ルールセットで別の方法が必須になっている場合、マージはブロックされます。 「GitHubのマージ メソッドについて」を参照してください。
帰属情報のない Copilot プル リクエストに対する追加の承認
メモ
この機能は パブリック プレビュー であり、変更される可能性があります。
Copilot は、新しいルールセットと既存のルールセットの両方で既定で有効になっています。 Copilotがユーザーに属性付けされていないプル要求を開くと、ルール セットには、構成した数よりも 1 つ多くの承認が必要です。 たとえば、1 つの承認を必要とするルールセットには、書き込みアクセス権を持つユーザーからの 2 つの承認が必要です。
通常、1 つの承認を要求するということは、2 人のユーザーが変更に関与することを意味します。変更を作成したユーザーと承認したユーザーです。 グループ スレッドやチャネルなどの共有コンテキストからプロンプトを表示する場合など、 Copilot がユーザーの代わりに独自のアプリ ID でプル要求を開いた場合、その前提は保持されません。 「Copilot クラウド エージェントと Slack の統合」と「Copilot クラウド エージェントと Teams の統合」を参照してください。
この設定は、ルール セットで承認が 0 個必要な場合は影響を受けないため、承認をゲートするのではなく、変更のレコードとしてプル要求を使用するリポジトリは影響を受けません。
この設定をオフにした場合、これらのプル要求には、構成した承認の数のみが必要です。 プッシュする最後のユーザー以外のユーザーからの承認も必要な場合は、少なくとも 1 つの承認が最後のプッシュをカバーし、 Copilot以外のユーザーから送信される必要があります。
必要なレビュー担当者
必要に応じて、プル要求によって特定のファイルまたはディレクトリが変更されたときに、特定のチームからのレビューまたは承認を要求できます。 最大 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 で構成されている場合は、ルールセットを使用して、次のいずれかの条件が満たされたときにプル要求がマージされないようにすることができます。
- 必要なツールは、ルール セットで定義されている重大度の code scanning アラートを検索します。
- 必要なツールの分析はまだ進行中です。
- リポジトリに必要なツールが構成されていません。
詳しくは、「コード スキャンのマージ保護を設定します」をご覧ください。 code scanningの一般的な情報については、AUTOTITLE を参照してください。
コード品質の結果を要求する
リポジトリが GitHub Code Quality で構成されている場合は、ルールセットを使用して、次のいずれかの条件が満たされたときにプル要求がマージされないようにすることができます。
- 分析はまだ進行中です。
- 分析はさまざまな理由で失敗することがあります。たとえば、アクション分の時間の予算を使い果たした場合です。
- Code Quality ルールセットで定義されているレベルの重大度、またはより高い重大度の結果が見つかりました。
詳細については、「GitHub のコード品質」および「プル要求のコード品質しきい値の設定」を参照してください。
コードカバレッジを制限する
メモ
この機能は パブリック プレビュー であり、変更される可能性があります。
リポジトリ GitHub Code Quality 有効になっており、コード カバレッジ データがアップロードされている場合は、ルールセットを使用して、コード カバレッジのしきい値に基づいてプル要求がマージされないようにすることができます。 カバレッジ データのアップロードの詳細については、 リポジトリのコード カバレッジの設定 を参照してください。
この規則は、次の 2 つのコード カバレッジしきい値のいずれかが満たされていない場合に、プル要求がマージされないようにブロックします。
- 最小ライン カバレッジ率: プル要求ブランチの集計されたライン カバレッジが、構成された割合を下回ります。
- 最大ライン カバレッジ ドロップ: ライン カバレッジは、既定の分岐に対して設定されたパーセンテージ ポイント数を超えて低下します。
しきい値を構成する方法、カバレッジ データをアップロードするための前提条件、およびルールを安全にロールアウトする方法については、 プル要求のコードカバレッジのしきい値の設定 を参照してください。
ファイル パスを制限する
指定したファイル パスの中に変更を含めているコミットが、リポジトリにプッシュされることを防止します。 制限は 200 エントリで、各エントリで最大 200 文字です。
これには fnmatch の構文を使用できます。 たとえば、test/demo/**/* を対象とする制限により、test/demo/ ディレクトリ内のファイルまたはフォルダーへのプッシュが禁止されます。 test/docs/pushrules.md を対象とした制限により、test/docs/ ディレクトリ内の pushrules.md ファイルへのプッシュが禁止されます。 詳しくは、「リポジトリのルールセットの作成」をご覧ください。
このルールに許可されている例外を追加することもできます。 許可された例外に一致するファイルは、制限されたパスにも一致する場合でもプッシュできます。
許可された例外は fnmatch 構文を使用し、ルールセットを保存するときに検証されます。 たとえば、 **/gradle/wrapper/*.jar では、任意のディレクトリで Gradle ラッパー JAR ファイルを使用できます。
ファイル パスの長さを制限する
指定した文字制限を超過するファイル パスを含むコミットが、リポジトリにプッシュされることを防止します。
ファイル拡張子を制限する
指定したファイル拡張子を持つファイルを含むコミットが、リポジトリにプッシュされることを防止します。 制限は 200 エントリで、各エントリで最大 200 文字です。
それ以外の種類のブロックされたファイルの 1 つのファイルに対して例外を許可する必要がある場合は、 **/*.jarなどのパターンで "ファイル パスの制限" を使用します。 許可される例外は、"ファイル パスの制限" ルールと "ファイル サイズの制限" 規則でのみサポートされます。
ファイル サイズを制限する
指定したファイル サイズ制限を超過するコミットが、リポジトリにプッシュされることを防止します。
このルールに許可されている例外を追加することもできます。 許可された例外に一致するファイルが、ファイル サイズの制限を超える可能性があります。
許可された例外は fnmatch 構文を使用し、ルールセットを保存するときに検証されます。 たとえば、 **/gradle/wrapper/*.jar では、任意のディレクトリで Gradle ラッパー JAR ファイルを使用できます。