ブランチ保護ルールについて
ブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。
デフォルト設定では、各ブランチ保護ルールは、一致するブランチへのフォースプッシュを無効にし、一致するブランチが削除されないようにします。 必要に応じて、これらの制限を無効にし、追加のブランチ保護設定を有効にすることができます。
既定では、ブランチ保護ルールの制限は、リポジトリの管理者アクセス許可持つユーザーまたは "ブランチ保護をバイパスする" アクセス許可を持つカスタム ロールには適用されません。 必要に応じて、管理者および "ブランチ保護をバイパスする" アクセス許可を持つロールにも、制限を適用できます。 詳細については、「Organizationのカスタムリポジトリロールの管理」を参照してください。
リポジトリ内のブランチ保護ルールは、特定のブランチ、すべてのブランチ、または fnmatch 構文で指定する名前のパターンに一致するあらゆるブランチに対して作成できます。 たとえば、release という単語を含む任意のブランチを保護するには、*release* のブランチ ルールを作成します。 ブランチ名のパターンについて詳しくは、「ブランチ保護ルールを管理する」をご覧ください。
すべてのマージの要件が満たされたときに、自動的にマージされるようにPull Requestを設定できます。 詳しくは、「プルリクエストを自動的にマージする」を参照してください。
ブランチ保護設定について
ブランチ保護ルールごとに、次の設定を有効にするか無効にするかを選択できます。
- [Require pull request reviews before merging](マージ前に pull request レビュー必須)
- マージ前にステータスチェック必須
- [Require conversation resolution before merging](マージ前に会話の解決必須)
- [Require signed commits](署名済みコミット必須)
- [Require linear history](直線状の履歴必須)
- マージ キュー必須
- マージの前にデプロイが成功する必要がある
- ブランチをロックする - 上の設定のバイパスを許可しない
- [Restrict who can push to matching branches](一致するブランチにプッシュできるユーザーを制限)
- [Allow force pushes](フォース プッシュを許可)
- [Allow deletions](削除を許可)
ブランチ保護を設定する方法について詳しくは、「ブランチ保護ルールを管理する」をご覧ください。
マージ前に Pull Request レビュー必須
リポジトリ管理者または "リポジトリ ルールの編集" アクセス許可を持つカスタム ロールは、保護されたブランチに他のユーザーがすべての pull request をマージする前に、特定の数の承認レビューがそれらの pull request に届くことを必須にすることができます。 リポジトリに書き込み権限を持っている人か、指定されたコードオーナーからの承認レビューを必須とすることができます。
必須レビューを有効にした場合、コラボレータは、書き込み権限を持つ必要な人数のレビュー担当者により承認されたプルリクエストからしか、保護されたブランチに変更をプッシュできなくなります。
管理者権限を持つユーザーがレビューで Request changes オプションを選択した場合、pull request をマージするためには、そのユーザーがその pull request を承認する必要があります。 プルリクエストへの変更をリクエストしたレビュー担当者の手が空いていない場合、そのリポジトリに書き込み権限を持つ人が、ブロックしているレビューを却下できます。
すべての必須のレビュー担当者がPull Requestを承認した後でも、同じコミットを指すヘッドブランチを持つ、保留中もしくは拒否されたレビューを持つオープンなPull Requestが他にある場合、コラボレータはそのPull Requestをマージできません。 まず、他のPull Request上のブロックしているレビューを、書き込み権限を持つ誰かが承認もしくは却下しなければなりません。
コラボレータが保留中または拒否されたレビューのプルリクエストを保護されたブランチにマージしようとすると、コラボレータにエラーメッセージが届きます。
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.必要に応じて、コミットがプッシュされた際に古いプルリクエストを却下できます。 コードを承認されたプルリクエストに変更するコミットがプッシュされた場合、その承認は却下され、プルリクエストはマージできません。 これは、ベースブランチをプルリクエストのブランチにマージするなど、コードを変更しないコミットをコラボレータがプッシュする場合には適用されません。 ベース ブランチについて詳しくは、「pull requests について」をご覧ください。
必要に応じて、プルリクエストレビューを却下する権限を、特定の人物またはチームに限定できます。 詳しくは、「プルリクエストレビューの却下」を参照してください。
必要に応じて、コードオーナー'からのレビューを必須にすることもできます。 この場合、コードオーナーのコードに影響するプルリクエストは、保護されたブランチにプルリクエストをマージする前に、そのコードオーナーから承認される必要があります。
必要に応じて、pull request をマージする前に、最後のユーザー以外のユーザーがブランチへのプッシュを承認することを要求できます。 これにより、保護されたブランチにマージされる前に、pull request の最終的な状態を複数のユーザーが確認できます。 この機能を有効にした場合、必要な承認ブランチ保護に関係なく、変更をプッシュする最後のユーザーが承認を必要とします。 pull request を既にレビューしているユーザーは、最後のプッシュの後でもう一度承認して、この要件を満たすことができます。
マージ前にステータスチェック必須
必須ステータスチェックにより、コラボレータが保護されたブランチに変更を加える前に、すべての必須 CI テストにパスしていることが保証されます。 詳細は「保護されたブランチを設定する」および「必須ステータスチェックを有効にする」を参照してください。 詳しくは、「ステータスチェックについて」を参照してください。
ステータス チェック必須を有効にする前に、コミット ステータス API を使うようにリポジトリを構成する必要があります。 詳しくは、REST API ドキュメントの「コミットのステータスについて」をご覧ください。
ステータスチェック必須を有効にすると、すべてのステータスチェック必須がパスしないと、コラボレータは保護されたブランチにマージできません。 必須ステータスチェックをパスしたら、コミットを別のブランチにプッシュしてから、マージするか、保護されたブランチに直接プッシュする必要があります。
リポジトリへの書き込み権限があるユーザーまたは統合は、リポジトリのステータス チェックを任意の状態に設定できますが、場合によっては特定の GitHub App のステータス チェックのみを受け入れる必要があります。 必須状態チェックを追加するとき、このチェックを最近設定したアプリを、状態更新が想定されるソースとして選べます。 状態が他のユーザーまたは統合によって設定されている場合、マージは許可されません。 any source を選択した場合は、マージ ボックスに一覧表示されている各状態の作成者を引き続き手動で確認することができます。
必須ステータスチェックのタイプは、[loose] (寛容)、[strict] (厳格) のいずれかに設定できます。 選択した必須ステータスチェックのタイプにより、マージする前にブランチをベースブランチとともに最新にする必要があるかどうかが決まります。
| 必須ステータスチェックのタイプ | 設定 | マージの要件 | 考慮事項 |
|---|---|---|---|
| Strict | Require branches to be up to date before merging チェックボックスをオンにします。 | ブランチは、マージ前にベース ブランチと同じ最新状態である必要があります。 | これは、必須ステータスチェックのデフォルト動作です。 他のコラボレーターが、保護された base ブランチにプルリクエストをマージした後に、あなたは head ブランチをアップデートする必要が出てくる可能性があるため、追加のビルドが必要になるかもしれません。 |
| Loose | Require branches to be up to date before merging チェックボックスをオンにしません。 | ブランチは、マージ前にベース ブランチと同じ最新状態である必要はありません。 | 他のコラボレーターがプルリクエストをマージした後に head ブランチをアップデートする必要はないことから、必要となるビルドは少なくなります。 base ブランチと競合する変更がある場合、ブランチをマージした後のステータスチェックは失敗する可能性があります。 |
| Disabled | Require status checks to pass before merging チェックボックスをオンにしません。 | ブランチのマージについての制限はない | 必須ステータスチェックが有効化されていない場合、base ブランチにあわせてアップデートされているかどうかに関わらず、コラボレーターはいつでもブランチをマージできます。 このことで、変更の競合が発生する可能性が高まります。 |
トラブルシューティング情報については、「必須ステータスチェックのトラブルシューティング」をご覧ください。
Require conversation resolution before merging
pull request を保護されたブランチにマージする前に、関連するすべてのコメントを解決する必要があります。 これにより、マージ前にすべてのコメントが対処または確認されます。
署名済みコミットの必須化
コミット署名の必須化をブランチで有効にすると、共同作成者とボットは、署名されて検証されたコミットのみをブランチにプッシュできます。 詳しくは、「コミット署名の検証について」を参照してください。
注:
- 警戒モード (コミットが常に署名される) を有効にした場合、GitHub によって Partially verified と識別されたすべてのコミットは、署名済みコミットが必須であるブランチで許可されます。 警戒モードについて詳しくは、「すべてのコミットの検証ステータスを表示する」をご覧ください。
- コラボレーターが未署名のコミットを、コミット署名必須のブランチにプッシュする場合、コラボレーターは検証済み署名を含めるためにコミットをリベースしてから、書き直したコミットをブランチにフォース プッシュする必要があります。
コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 GitHub Enterprise Cloud の pull request を使用して、署名および検証されているコミットをブランチにマージすることもできます。 ただし、pull request の作者でない限り、pull request をスカッシュして GitHub Enterprise Cloud のブランチにマージすることはできません。pull request をローカルでスカッシュおよびマージできます。 詳しくは、「プルリクエストをローカルでチェック アウトする」を参照してください。
マージ方法について詳しくは、「GitHub上のマージ方法について」をご覧ください。
直線状の履歴必須
直線状のコミット履歴を強制すると、コラボレータがブランチにマージコミットをプッシュすることを防げます。 つまり、保護されたブランチにマージされたプルリクエストは、squash マージまたはリベースマージを使用する必要があります。 厳格な直線状のコミット履歴は、Teamが変更をより簡単にたどるために役立ちます。 マージ方法について詳しくは、「プルリクエストのマージについて」をご覧ください。
直線状のコミット履歴をリクエストする前に、リポジトリで squash マージまたはリベースマージを許可する必要があります。 詳しくは、「プルリクエストマージを設定する」を参照してください。
[Require merge queue](マージ キュー必須)
注: pull request のマージ キュー機能は現在、パブリック ベータ版であり、変更される可能性があります。
マージ キューを使用すると、必要なすべてのブランチ保護チェックに合格することを保証しつつ、pull request がビジー状態のターゲット ブランチにマージされる速度を上げることができます。
pull request が必要なすべてのブランチ保護チェックに合格すると、リポジトリへの書き込みアクセス権を持つユーザーは、その pull request をマージ キューに追加できます。
マージ キューでは、GitHub Actions を使用できます。 詳しくは、「GitHub Actionsのドキュメント」を参照してください。
GitHub Enterprise Cloud は、必要なすべての CI チェックに合格すると、ブランチ保護で構成されたマージ戦略に従って pull request をマージします。
Require deployments to succeed before merging
ブランチをマージする前に、変更が特定の環境に正常にデプロイされる必要があるように設定できます。 たとえば、この規則を使用し、変更がステージング環境に正常にデプロイされた後で、変更を既定のブランチにマージされるようにすることができます。
ブランチをロックする
ブランチをロックすると、ブランチに対してコミットを行えなくなります。 既定では、フォークされたリポジトリでは、アップストリーム リポジトリからの同期はサポートされていません。 [フォークの同期を許可する] を有効にして、フォークのブランチへの他のコントリビューションを防ぎながら、アップストリーム リポジトリから変更をプルできます。
上の設定のバイパスを許可しない
既定では、ブランチ保護ルールの制限は、リポジトリの管理者アクセス許可持つユーザーまたはリポジトリでの "ブランチ保護をバイパスする" アクセス許可を持つカスタム ロールには適用されません。
この設定を有効にして、管理者および "ブランチ保護をバイパスする" アクセス許可を持つロールにも、制限を適用できます。 詳細については、「Organizationのカスタムリポジトリロールの管理」を参照してください。
一致するブランチにプッシュできるユーザを制限
GitHub Free 組織によって所有されているパブリック リポジトリと、GitHub Team または GitHub Enterprise Cloud を使って組織によって所有されているすべてのリポジトリで、ブランチ制限を有効にできます。
ブランチ制限を有効にすると、権限を与えられたユーザ、チーム、またはアプリのみが保護されたブランチにプッシュできます。 保護されたブランチの設定で、保護されたブランチへのプッシュアクセスを使用して、ユーザ、チーム、またはアプリを表示および編集できます。 状態チェックが必須である場合は、必須チェックに失敗すると、保護されたブランチにプッシュするアクセス許可を持つユーザー、チーム、アプリでも、ブランチにマージすることはできません。 pull request が必須な場合は、保護されたブランチにプッシュするアクセス許可を持つユーザー、チーム、アプリでも pull request を作成する必要があります。
必要に応じて、規則と一致するブランチの作成に同じ制限を適用できます。 たとえば、release という語を含むブランチに特定のチームのみがプッシュすることを許可する規則を作成した場合は、そのチームのメンバーしか release という語を含む新しいブランチを作成できません。
保護されたブランチに対するプッシュ アクセスを付与したり、一致するブランチを作成するアクセス許可を付与したりできるのは、リポジトリへの書き込みアクセスを持つ、ユーザー、チーム、またはインストール済みの GitHub Apps のみです。 リポジトリへの管理者権限を持つユーザーとアプリは、保護されたブランチへのプッシュや一致するブランチの作成をいつでも行うことができます。
フォースプッシュを許可
デフォルトでは、GitHub Enterprise Cloud はすべての保護されたブランチでフォースプッシュをブロックします。 保護されたブランチへのフォース プッシュを有効にするとき、フォース プッシュを行うことができる 2 つのグループのいずれかを選択できます。
- リポジトリに対して少なくとも書き込みアクセス許可を持つすべてのユーザー (管理者権限を持つユーザーを含む) が、ブランチにフォース プッシュできるようにします。
- 特定のユーザーまたはチームのみがブランチにフォース プッシュできるようにします。
誰かがブランチにフォース プッシュした場合、フォース プッシュによって、他のコラボレーターがそれに基づいて作業しているコミットを上書きする可能性があります。 ユーザーが競合をマージしたり pull request を破損させたりした可能性があります。
フォースプッシュを有効化しても、他のブランチ保護ルールは上書きされません。 たとえば、ブランチに直線状のコミット履歴が必要な場合、そのブランチにマージコミットをフォースプッシュすることはできません。
削除を許可
デフォルトでは、保護されたブランチは削除できません。 保護されたブランチの削除を有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、ブランチを削除できます。