ブランチまたはタグのルールセットを作成して、ユーザーがリポジトリ内で選んだブランチとタグを操作する方法を制御できます。
ルールセットを作成するときに、特定のユーザーがルールセットの中のルールをバイパスすることを許可できます。 これは、特定のロールを持つユーザー、特定のチーム、または GitHub Apps です。
ルールセットとバイパスアクセス許可の作成の詳細については、「リポジトリのルールセットの作成」を参照してください。
作成を制限する
これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグを作成できます。
更新を制限する
これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグにプッシュできます。
削除を制限する
これを選ぶと、バイパス アクセス許可を持つユーザーだけが、指定したパターンに一致する名前のブランチまたはタグを削除できます。 このルールは既定で選ばれています。
直線状の履歴必須
直線状のコミット履歴を強制すると、コラボレーターがターゲットとするブランチにマージ コミットをプッシュすることを防げます。 つまり、ブランチまたはタグにマージされる pull request は、スカッシュ マージまたはリベース マージを使用する必要があります。 厳密に線形なコミット履歴は、チームが変更点をより簡単に元に戻すのに役立ちます。 マージ方法の詳細については、「プルリクエストのマージについて」を参照してください。
直線状のコミット履歴をリクエストする前に、リポジトリで squash マージまたはリベースマージを許可する必要があります。 詳しくは、「プルリクエストマージを設定する」をご覧ください。
マージ前に展開の成功が必須です
Note
このルールは、Organization レベルで作成されたルールセットでは使用できません。
ブランチをマージする前に、変更が特定の環境に正常にデプロイされる必要があるように設定できます。 たとえば、この規則を使用し、変更がステージング環境に正常にデプロイされた後で、変更を既定のブランチにマージされるようにすることができます。
署名済みコミットの必須化
コミット署名の必須化をブランチで有効にすると、共同作成者は、署名されて検証されたコミットのみをブランチにプッシュできます。 詳しくは、「コミット署名の検証について」をご覧ください。
ブランチ保護ルールとルールセットは、ブランチを作成するときのビヘイビアーが異なります。ルールセットでは、他のブランチからアクセスできないコミットのみをチェックしますが、ブランチ保護ルールでは、一致するブランチを作成するプッシュを制限しない限り、署名されたコミットは検証されません。 両方とも、ブランチを更新すると、他のブランチからコミットに到達できる場合でも、指定された範囲内のすべてのコミットをチェックします。
どちらの方法でも、verified_signature? を使用してコミットに有効な署名があるかどうかを確認します。 有効な署名がない場合、更新は受け入れられません。
Note
コラボレーターが未署名のコミットを、コミット署名必須のブランチにプッシュする場合、コラボレーターは検証済み署名を含めるためにコミットをリベースしてから、書き直したコミットをブランチにフォース プッシュする必要があります。
コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 ただし、pull request を GitHub Enterprise Server のブランチにマージすることはできません。pull request をローカルでマージできます。 詳しくは、「プルリクエストをローカルでチェック アウトする」をご覧ください。
マージ前の 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 を選択した場合は、マージ ボックスに一覧表示されている各状態の作成者を引き続き手動で確認することができます。
Note
組織レベルのステータス チェックの場合は、statuses:write 権限を持つアプリをインストールする必要があります。 組織レベルでルールセットを構成する場合、このアクセス許可を持つアプリのみが表示されます。
必須ステータス チェックは、"緩い" または "厳格" のいずれかであると考えることができます。 選択した必須ステータスチェックのタイプにより、マージする前にブランチをベースブランチとともに最新にする必要があるかどうかが決まります。
| 必須ステータスチェックのタイプ | 設定 | マージの要件 | 考慮事項 |
|---|---|---|---|
| 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 でブランチが削除されたり、承認されていないコミットがブランチでポイントされたりする可能性もあります。
強制プッシュを有効にしても、他のルールはオーバーライドされません。 たとえば、ブランチに直線状のコミット履歴が必要な場合、そのブランチにマージコミットをフォースプッシュすることはできません。
サイト管理者がリポジトリ内のすべてのブランチへの強制プッシュをブロックしている場合、ブランチの強制プッシュを有効にすることはできません。 詳しくは、「Enterprise でリポジトリ管理ポリシーを適用する」をご覧ください。
サイト管理者が既定のブランチへの強制プッシュのみをブロックしている場合、他のブランチに対して強制プッシュを有効にできます。
マージ前にワークフローに渡すことを必須にする
ルールセット ワークフローは、プル リクエストを統合する前にワークフローが渡されるように組織レベルで構成できます。 詳しくは、「組織内のリポジトリのルールセットを作成する」を参照してください。
一般的なルールセット ワークフローの構成設定のトラブルシューティングの詳細については、「ルールのトラブルシューティング」を参照してください。
ワークフロー ファイルの使用
このルールを使用するには、最初にワークフロー ファイルを作成する必要があります。 ワークフロー ファイルは、それを実行するリポジトリと同じ可視性を持つリポジトリに置く必要があります。 具体的には、パブリック ワークフローは組織内の任意のリポジトリで実行でき、内部ワークフローは内部リポジトリとプライベート リポジトリでのみ実行でき、プライベート ワークフローはプライベート リポジトリでのみ実行できます。 詳しくは、「ワークフローについて」をご覧ください。
ワークフロー ファイルが内部リポジトリまたはプライベート リポジトリに存在し、組織内の他のリポジトリでそのワークフローを使用する場合は、リポジトリの外部からワークフローにアクセスできるようにする必要があります。 詳細については、「内部リポジトリ内のコンポーネントへのアクセスを許可する」または「プライベート リポジトリ内のコンポーネントへのアクセスを許可する」を参照してください。
このルールをルールセットに追加する際には、組織の設定で、ソース リポジトリと適用するワークフローを選択します。
ルールセット ワークフローに「評価」モードを使用する
ルールセット ワークフローが「評価」モードで実行され、パスした場合は、ルールセット ワークフローを「アクティブ」モードに設定し、新しいワークフロー実行をトリガーせずにプル リクエストを統合できます。
「評価」モードでルールセットを作成する前にプル リクエストを開くと、ルールセットが適用されないため、引き続きそのプル リクエストを統合できます。
適用ステータスの詳細については、「リポジトリのルールセットの作成」を参照してください。
サポートされているイベント トリガー
ルールセット ワークフローでは、pull_request、pull_request_target および merge_group イベントの使用がサポートされます。 その結果、ワークフローがルールセットによって実行されるように、ワークフローの on: セクションで、これらのイベントのうち 1 個以上を指定する必要があります。
サポートされているイベントに対して指定したフィルターは無視されます - 例: branches、 branches-ignore、 paths など types。 ワークフローは、サポートされているイベントの既定のアクティビティの種類によってのみトリガーされ、すると常に作動します。
| イベント | 既定のアクティビティの種類 |
|---|---|
pull_request | opened, synchronize, reopened |
pull_request_target | opened, synchronize, reopened |
merge_group | checks_requested |
ルールセット ワークフローを使用した特定のブランチのターゲット設定
ルールセット ワークフローはプル リクエストと統合 キュー エクスペリエンスの一部として実行されるため、このルールを適用すると直接プッシュがブロックされます。 このため、リポジトリ内のすべてのブランチを対象とするルールセットにこのルールを適用しないでください。
このルールは、ブランチに対するすべての変更がプル リクエストによって実行されるブランチを対象とするルールセットにのみ追加する必要があります。
メタデータの制限
Note
ブランチをスカッシュ マージする場合、そのブランチに対するすべてのコミットは、ベース ブランチのメタデータ要件を満たす必要があります。
GitHub Enterprise プランを利用している組織は、コミット メタデータの書式を制御する追加のルールにアクセスできます。 リテラル文字列または正規表現構文を使用して、コミット メタデータが準拠する必要があるパターンを定義できます。 たとえば、コミット メッセージに GitHub の issue 番号が含まれていることや、コミッターまたは作者が @octoorg.com で終わるメール アドレスを持っていることを必須にすることができます。 新しいブランチ名とタグ名の形式を制御することもできます。 コミット メタデータに役立つ正規表現を集めた「リポジトリのルールセットの作成」を参照してください。
コントリビューターが要件を満たしていないコミットでブランチまたはタグを更新しようとすると、コントリビューターにコミットの何が問題かを示すエラーが表示されます。 このエラーは、コマンド ライン (ユーザーがプッシュするとき) と GitHub.com (ユーザーが pull request をコミットまたはマージしようとしたとき) の両方に表示される可能性があります。 Git ではコミットは変更不可です。コントリビューターは、コミットを作成した後はコミットのメタデータを編集できないため、リポジトリに作業を正常に投稿する前に、コミット履歴を新しいコミットで書き換えるためにリベースを実行することが必要な場合があります。
メタデータ制限は、ブランチの履歴におけるコミット間の整合性を強制する場合に役立ちます。 これは、従来のコミットの仕様などのベスト プラクティスへの準拠を強制する場合や、コミット メタデータに依存するツールとの統合に役立ちます。 たとえば、各メッセージが予測可能な形式に準拠していれば、コミット メッセージの内容に基づいてスクリプトを実行することが簡単になります。 カスタムの pre-receive フック スクリプトを設定する代わりにメタデータ制限を使用することもできます。 詳細については、「[AUTOTITLE] (/admin/policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks)」を参照してください。
メタデータ制限に関する重要な考慮事項
メタデータ制限では、"ref updates" がブロックされます。 コントリビューターが要件を満たしていないコミットを含む作業をプッシュした場合、プッシュは拒否されませんが、ターゲットとするブランチまたはタグは更新されません。 技術的には、その場合でもコミットはリポジトリに反映されます。コミットは "取得可能" (リポジトリ内でそこに移動できる) になりますが、"到達可能" ではありません (ブランチまたはタグの履歴に接続されません)。 共同作成者のプッシュに、それらのブランチまたはタグの要件を満たすコミットを含む他のブランチまたはタグに対する作業も含まれている場合、それらの参照は正常に更新されます。
メタデータ制限により、リポジトリへのコントリビューションを行うユーザーにとっては、摩擦が増える可能性があります。 一般に、メタデータ制限を適用する場合は、共同作成者の日常の作業に影響を与えないように、限られたブランチ セットに対して行う必要があります。 たとえば、共同作成者が作業する可能性のあるトピック ブランチで一貫性のあるコミット メッセージを必須とするのではなく、main でのみ一貫性のあるコミット メッセージを必須にしてから、main への pull request を必須にする必要があります。
スカッシュ マージを使う場合、メタデータの制限はマージ前に評価されるので、pull request のすべてのコミットが要件を満たす必要があることに注意してください。 コミッター メールに適用されるメタデータ制限の場合、制限を満たすためのスカッシュ マージの noreply@github.com もパターンに含める必要があります。
既存のブランチまたはタグにメタデータ制限を追加すると、その時点から以降にブランチまたはタグにプッシュされた新しいコミットに対してルールが適用されますが、ブランチまたはタグの既存の履歴に対しては適用されません。