ブランチ保護ルールについて
ブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。
デフォルト設定では、各ブランチ保護ルールは、一致するブランチへのフォースプッシュを無効にし、一致するブランチが削除されないようにします。 必要に応じて、これらの制限を無効にし、追� のブランチ保護設定を有効にすることができます。
デフォルト設定では、ブランチ保護ルールの制限は、リポジトリへの管理者権限を持つユーザには適用されません。 必要に応じて、管理者を含めることもできます。
リポジトリ内のブランチ保護ルールは、特定のブランチ、あるいはすべてのブランチや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 ドキュメントの「リポジトリ」を参照してく� さい。
ステータスチェック必� �を有効にすると、すべてのステータスチェック必� �がパスしないと、コラボレータは保護されたブランチにマージできません。 必� �ステータスチェックをパスしたら、コミットを別のブランチにプッシュしてから、マージするか、保護されたブランチに直接プッシュする必要があります。
Any person or integration with write permissions to a repository can set the state of any status check in the repository If the status is set by any other person or integration, merging won't be allowed. If you select "any source", you can still manually verify the author of each status, listed in the merge box.
必� �ステータスチェックのタイプは、[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 マージまたはリベースマージを許可する必要があります。 詳しい情� �については、「プルリクエストマージを設定する」を参照してく� さい。
管理者を含める
デフォルトでは、保護されたブランチのルールは、リポジトリの管理者権限を持つユーザには適用されません。 この設定を有効化すると、保護されたブランチのルールを管理者にも適用できます。
一致するブランチにプッシュできるユーザを制限
ブランチ制限を有効にすると、権限を与えられたユーザ、チー� 、またはアプリのみが保護されたブランチにプッシュできます。 保護されたブランチの設定で、保護されたブランチへのプッシュアクセスを使用して、ユーザ、チー� 、またはアプリを表示および編集できます。 When status checks are required, the people, teams, and apps that have permission to push to a protected branch will still be prevented from merging if the required checks fail. People, teams, and apps that have permission to push to a protected branch will still need to create a pull request when pull requests are required.
ユーザ、チー� 、またはリポジトリへの write 権限を持つインストール済みの GitHub Apps にのみ、保護されたブランチへのプッシュアクセス付与できます。 リポジトリへの管理者権限を持つユーザとアプリケーションは、いつでも保護されたブランチにプッシュできます。
フォースプッシュを許可
デフォルトでは、GitHub Enterprise Serverはすべての保護されたブランチでフォースプッシュをブロックします。 保護されたブランチのフォースプッシュを有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、管理者権限を持つブランチを含め、ブランチをフォースプッシュできます。 If someone force pushes to a branch, the force push may overwrite commits that other collaborators based their work on. People may have merge conflicts or corrupted pull requests.
フォースプッシュを有効化しても、他のブランチ保護ルールは上書きされません。 たとえば、ブランチに直線状のコミット履歴が必要な� �合、そのブランチにマージコミットをフォースプッシュすることはできません。
サイト管理者がリポジトリ内のすべてのブランチへのフォースプッシュをブロックしている� �合、保護されたブランチのフォースプッシュを有効にすることはできません。 詳しい情� �については、「ユーザアカウントもしくはOrganizationが所有するリポジトリへのフォースプッシュのブロック」を参照してく� さい。
サイト管理者がデフォルトブランチへのフォースプッシュのみをブロックしている� �合、他の保護されたブランチに対してフォースプッシュを有効にできます。
削除を許可
デフォルトでは、保護されたブランチは削除できません。 保護されたブランチの削除を有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、ブランチを削除できます。