ブランチ保護ルールについて
ブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。
デフォルト設定では、各ブランチ保護ルールは、一致するブランチへのフォースプッシュを無効にし、一致するブランチが削除されないようにします。 必要に応じて、これらの制限を無効にし、追加のブランチ保護設定を有効にすることができます。
デフォルト設定では、ブランチ保護ルールの制限は、リポジトリへの管理者権限を持つユーザには適用されません。 必要に応じて、管理者を含めることもできます。
リポジトリ内のブランチ保護ルールは、特定のブランチ、あるいはすべてのブランチやfnmatch構文で指定した名前のパターンにマッチするブランチに対して作成できます。 たとえば、releaseという語を含む任意のブランチを保護するには、ブランチルールを*release*に対して作成できます。 ブランチ名のパターンの詳細については、「ブランチ保護ルールを管理する」を参照してください。
ブランチ保護設定について
ブランチ保護ルールごとに、次の設定を有効にするか無効にするかを選択できます。
For more information on how to set up branch protection, see "Managing a branch protection rule."
マージ前に Pull Request レビュー必須
リポジトリ管理者はすべてのPull Requestに対し、保護されたブランチにPull Requestを誰かがマージできるようになる前に受けなければならない承認レビューの数を指定できます。 リポジトリに書き込み権限を持っている人か、指定されたコードオーナーからの承認レビューを必須とすることができます。
必須レビューを有効にした場合、コラボレータは、書き込み権限を持つ必要な人数のレビュー担当者により承認されたプルリクエストからしか、保護されたブランチに変更をプッシュできなくなります。
管理者権限を持つ人がレビューで [Request changes] を選択した場合、プルリクエストをマージするためには管理者権限を持つ人がそのプルリクエストを承認する必要があります。 プルリクエストへの変更をリクエストしたレビュー担当者の手が空いていない場合、そのリポジトリに書き込み権限を持つ人が、ブロックしているレビューを却下できます。
すべての必須のレビュー担当者が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.必要に応じて、コミットがプッシュされた際に古いプルリクエストを却下できます。 コードを承認されたプルリクエストに変更するコミットがプッシュされた場合、その承認は却下され、プルリクエストはマージできません。 これは、ベースブランチをプルリクエストのブランチにマージするなど、コードを変更しないコミットをコラボレータがプッシュする場合には適用されません。 ベースブランチに関する詳しい情報については「プルリクエストについて」を参照してください。
必要に応じて、プルリクエストレビューを却下する権限を、特定の人物またはチームに限定できます。 詳しい情報についてはプルリクエストレビューの却下を参照してください。
必要に応じて、コードオーナー'からのレビューを必須にすることもできます。 この場合、コードオーナーのコードに影響するプルリクエストは、保護されたブランチにプルリクエストをマージする前に、そのコードオーナーから承認される必要があります。
マージ前にステータスチェック必須
必須ステータスチェックにより、コラボレータが保護されたブランチに変更を加える前に、すべての必須 CI テストにパスしていることが保証されます。 詳細は「保護されたブランチを設定する」および「必須ステータスチェックを有効にする」を参照してください。 詳しい情報については、「ステータスチェックについて」を参照してください。
ステータスチェック必須を有効にする前に、ステータス API を使用するようにリポジトリを設定する必要があります。 詳しい情報については、REST ドキュメントの「リポジトリ」を参照してください。
ステータスチェック必須を有効にすると、すべてのステータスチェック必須がパスしないと、コラボレータは保護されたブランチにマージできません。 必須ステータスチェックをパスしたら、コミットを別のブランチにプッシュしてから、マージするか、保護されたブランチに直接プッシュする必要があります。
注釈: リポジトリへの書き込み権限があるユーザまたはインテグレーションなら誰でも、リポジトリのステータスチェックを任意のステータスに設定できます。 GitHub は、チェックの作者が、特定の名前でチェックを作成したり、既存のステータスを変更したりする権限を持っているかを確認しません。 プルリクエストをマージする前に、マージボックスにリストされている各ステータスの作者が想定された人物であることを確認する必要があります。
必須ステータスチェックのタイプは、[loose] (寛容)、[strict] (厳格) のいずれかに設定できます。 選択した必須ステータスチェックのタイプにより、マージする前にブランチをベースブランチとともに最新にする必要があるかどうかが決まります。
| 必須ステータスチェックのタイプ | 設定 | マージの要件 | 留意点 |
|---|---|---|---|
| Strict | [Require branches to be up to date before merging] チェックボックスにチェックする | マージ前、ブランチは、base ブランチとの関係で最新でなければならない。 | これは、必須ステータスチェックのデフォルト動作です。 他のコラボレーターが、保護された base ブランチにプルリクエストをマージした後に、あなたは head ブランチをアップデートする必要が出てくる可能性があるため、追加のビルドが必要になるかもしれません。 |
| Loose | [Require branches to be up to date before merging] チェックボックスにチェックしない | マージ前、ブランチは base ブランチとの関係で最新でなくてもよい。 | 他のコラボレーターがプルリクエストをマージした後に head ブランチをアップデートする必要はないことから、必要となるビルドは少なくなります。 base ブランチと競合する変更がある場合、ブランチをマージした後のステータスチェックは失敗する可能性があります。 |
| 無効 | [Require status checks to pass before merging] チェックボックスにチェックしない | ブランチのマージについての制限はない | 必須ステータスチェックが有効化されていない場合、base ブランチにあわせてアップデートされているかどうかに関わらず、コラボレーターはいつでもブランチをマージできます。 このことで、変更の競合が発生する可能性が高まります。 |
トラブルシューティング情報については、「必須ステータスチェックのトラブルシューティング」を参照してください。
署名済みコミットの必須化
ブランチで必須のコミット署名を有効にすると、コントリビュータは、ブランチに署名および検証されたコミットのみをプッシュできます。 詳細については、「コミット署名の検証について」を参照してください。
注釈: コラボレータが未署名のコミットをコミット署名必須のブランチにプッシュすると、コラボレータは検証済み署名を含めるためにコミットをリベースしてから、書き直したコミットをブランチにフォースプッシュする必要があります。
コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 ただし、プルリクエストをGitHub Enterprise Serverのブランチにマージすることはできません。プルリクエストをローカルでマージできます。 詳しい情報については、「プルリクエストをローカルでチェック アウトする」を参照してください。
直線状の履歴必須
直線状のコミット履歴を強制すると、コラボレータがブランチにマージコミットをプッシュすることを防げます。 つまり、保護されたブランチにマージされたプルリクエストは、squash マージまたはリベースマージを使用する必要があります。 厳格な直線状のコミット履歴は、Teamが変更をより簡単にたどるために役立ちます。 マージ方法に関する詳しい情報については「プルリクエストマージについて」を参照してください。
直線状のコミット履歴をリクエストする前に、リポジトリで squash マージまたはリベースマージを許可する必要があります。 詳しい情報については、「プルリクエストマージを設定する」を参照してください。
管理者を含める
デフォルトでは、保護されたブランチのルールは、リポジトリの管理者権限を持つユーザには適用されません。 この設定を有効化すると、保護されたブランチのルールを管理者にも適用できます。
一致するブランチにプッシュできるユーザを制限
ブランチ制限を有効にすると、権限を与えられたユーザ、チーム、またはアプリのみが保護されたブランチにプッシュできます。 保護されたブランチの設定で、保護されたブランチへのプッシュアクセスを使用して、ユーザ、チーム、またはアプリを表示および編集できます。
ユーザ、チーム、またはリポジトリへの write 権限を持つインストール済みの GitHub Apps にのみ、保護されたブランチへのプッシュアクセス付与できます。 リポジトリへの管理者権限を持つユーザとアプリケーションは、いつでも保護されたブランチにプッシュできます。
フォースプッシュを許可
デフォルトでは、GitHub Enterprise Serverはすべての保護されたブランチでフォースプッシュをブロックします。 保護されたブランチのフォースプッシュを有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、管理者権限を持つブランチを含め、ブランチをフォースプッシュできます。
フォースプッシュを有効化しても、他のブランチ保護ルールは上書きされません。 たとえば、ブランチに直線状のコミット履歴が必要な場合、そのブランチにマージコミットをフォースプッシュすることはできません。
サイト管理者がリポジトリ内のすべてのブランチへのフォースプッシュをブロックしている場合、保護されたブランチのフォースプッシュを有効にすることはできません。 詳しい情報については、「ユーザアカウントもしくはOrganizationが所有するリポジトリへのフォースプッシュのブロック」を参照してください。
サイト管理者がデフォルトブランチへのフォースプッシュのみをブロックしている場合、他の保護されたブランチに対してフォースプッシュを有効にできます。
削除を許可
デフォルトでは、保護されたブランチは削除できません。 保護されたブランチの削除を有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、ブランチを削除できます。