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

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

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

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

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

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

この記事の内容

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

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

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

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

作成を制限する

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

更新を制限する

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

削除を制限する

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

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

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

マージ前に展開の成功が必須です

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

署名済みコミットの必須化

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

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

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

Note

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

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

マージ方法について詳しくは、「GitHub上のマージ方法について」をご覧ください。

マージ前の pull request を必須にする

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

追加設定

Note

[新たなコミットがプッシュされたときに古い 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 の状態を記録します。この状態は、レビュー担当者が承認した一連の変更を表します。この状態から 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 をブランチにマージする前に、関連するすべてのコメントを解決する必要があるように設定できます。これにより、マージ前にすべてのコメントが対処または確認されます。

マージ前にステータスチェックにパスすることを必須にする

必須ステータスチェックにより、コラボレーターがルールセットの適用対象であるブランチまたはタグに変更を加える前に、すべての必須 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 ブランチにあわせてアップデートされているかどうかに関わらず、コラボレーターはいつでもブランチをマージできます。このことで、変更の競合が発生する可能性が高まります。

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

code scanning のマージ保護の設定

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

必要なツールで、ルールセットで定義している重大度の code scanning アラートが見つかりました。
必要な code scanning ツールはまだ分析中です。
必要な code scanning ツールはリポジトリ用に構成されていません。

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

強制プッシュのブロック

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

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

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