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

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

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

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

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

作成を制限する

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

更新を制限する

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

削除を制限する

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

直線状の履歴必須

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

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

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

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

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

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

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

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

コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 GitHub の 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 の状態を記録します。 この状態は、レビュー担当者が承認した一連の変更を表します。 この状態から 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上のマージ方法について」をご覧ください。

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

必須ステータス チェックにより、コラボレーターがルールセットの適用対象であるブランチまたはタグに変更を加える前に、すべての必須 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 でブランチが削除されたり、承認されていないコミットがブランチでポイントされたりする可能性もあります。

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

ファイル パスを制限する

指定したファイル パスに変更を含むコミットがリポジトリにプッシュされないようにします。

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

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

指定した文字制限を超えるファイル パスを含むコミットがリポジトリにプッシュされないようにします。

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

指定したファイル拡張子を持つファイルを含むコミットがリポジトリにプッシュされないようにします。

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

指定したファイル サイズ制限を超えるコミットがリポジトリにプッシュされないようにします。