Skip to main content
ドキュメントには� �繁に更新が� えられ、その都度公開されています。本ページの翻訳はま� 未完成な部分があることをご了承く� さい。最新の情� �については、英語のドキュメンテーションをご参照く� さい。本ページの翻訳に問題がある� �合はこちらまでご連絡く� さい。

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

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

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

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

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

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

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

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

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

直線状の履歴必� �

直線状のコミット履歴を強制すると、コラボレータがブランチにマージコミットをプッシュすることを防げます。 つまり、保護されたブランチにマージされたプルリクエストは、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 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.

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

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

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

削除を許可

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