Skip to main content
ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。
GitHub AEは、現在限定リリース中です。詳細については営業チームにお問い合わせください。

保護されたブランチについて

重要なブランチを保護するには、ブランチ保護ルールを設定します。このルールは、コラボレータがブランチへのプッシュを削除または強制できるかどうかを定義し、ステータスチェックのパスや直線状のコミット履歴など、ブランチへのプッシュの要件を設定します。

保護されたブランチは、GitHub AEのインターナル及びプライベートリポジトリ、GitHub Free及びOrganizationのGitHub Freeのパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのパブリック及びプライベートリポジトリで利用できます。

ブランチ保護ルールについて

ブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。

デフォルト設定では、各ブランチ保護ルールは、一致するブランチへのフォースプッシュを無効にし、一致するブランチが削除されないようにします。 必要に応じて、これらの制限を無効にし、追加のブランチ保護設定を有効にすることができます。

デフォルト設定では、ブランチ保護ルールの制限は、リポジトリへの管理者権限を持つユーザには適用されません。 必要に応じて、管理者を含めることもできます。

リポジトリ内のブランチ保護ルールは、特定のブランチ、あるいはすべてのブランチやfnmatch構文で指定した名前のパターンにマッチするブランチに対して作成できます。 たとえば、releaseという語を含む任意のブランチを保護するには、ブランチルールを*release*に対して作成できます。 ブランチ名のパターンの詳細については、「ブランチ保護ルールを管理する」を参照してください。

すべてのマージの要件が満たされたときに、自動的にマージされるようにPull Requestを設定できます。 詳しい情報については「Pull Requestの自動マージ」を参照してください。

ブランチ保護設定について

ブランチ保護ルールごとに、次の設定を有効にするか無効にするかを選択できます。

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 ブランチにあわせてアップデートされているかどうかに関わらず、コラボレーターはいつでもブランチをマージできます。 このことで、変更の競合が発生する可能性が高まります。

トラブルシューティング情報については、「必須ステータスチェックのトラブルシューティング」を参照してください。

Require conversation resolution before merging

Requires all comments on the pull request to be resolved before it can be merged to a protected branch. This ensures that all comments are addressed or acknowledged before merge.

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

ブランチで必須のコミット署名を有効にすると、コントリビュータは、ブランチに署名および検証されたコミットのみをプッシュできます。 詳細については、「コミット署名の検証について」を参照してください。

注釈: コラボレータが未署名のコミットをコミット署名必須のブランチにプッシュすると、コラボレータは検証済み署名を含めるためにコミットをリベースしてから、書き直したコミットをブランチにフォースプッシュする必要があります。

コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 ただし、プルリクエストをGitHub AEのブランチにマージすることはできません。プルリクエストをローカルでマージできます。 詳しい情報については、「プルリクエストをローカルでチェック アウトする」を参照してください。

直線状の履歴必須

直線状のコミット履歴を強制すると、コラボレータがブランチにマージコミットをプッシュすることを防げます。 つまり、保護されたブランチにマージされたプルリクエストは、squash マージまたはリベースマージを使用する必要があります。 厳格な直線状のコミット履歴は、Teamが変更をより簡単にたどるために役立ちます。 マージ方法に関する詳しい情報については「プルリクエストマージについて」を参照してください。

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

Require deployments to succeed before merging

You can require that changes are successfully deployed to specific environments before a branch can be merged. For example, you can use this rule to ensure that changes are successfully deployed to a staging environment before the changes merge to your default branch.

管理者を含める

デフォルトでは、保護されたブランチのルールは、リポジトリの管理者権限を持つユーザには適用されません。 この設定を有効化すると、保護されたブランチのルールを管理者にも適用できます。

一致するブランチにプッシュできるユーザを制限

ブランチ制限を有効にすると、権限を与えられたユーザ、チーム、またはアプリのみが保護されたブランチにプッシュできます。 保護されたブランチの設定で、保護されたブランチへのプッシュアクセスを使用して、ユーザ、チーム、またはアプリを表示および編集できます。 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 into the branch when 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.

You can only give push access to a protected branch, or give permission to create a matching branch, to users, teams, or installed GitHub Apps with write access to a repository. People and apps with admin permissions to a repository are always able to push to a protected branch or create a matching branch.

フォースプッシュを許可

デフォルトでは、GitHub AEはすべての保護されたブランチでフォースプッシュをブロックします。 保護されたブランチのフォースプッシュを有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、管理者権限を持つブランチを含め、ブランチをフォースプッシュできます。 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.

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

サイト管理者がリポジトリ内のすべてのブランチへのフォースプッシュをブロックしている場合、保護されたブランチのフォースプッシュを有効にすることはできません。 For more information, see "Blocking force pushes to repositories owned by a personal account or organization."

サイト管理者がデフォルトブランチへのフォースプッシュのみをブロックしている場合、他の保護されたブランチに対してフォースプッシュを有効にできます。

削除を許可

デフォルトでは、保護されたブランチは削除できません。 保護されたブランチの削除を有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、ブランチを削除できます。