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

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


You can protect important branches by setting branch protection rules, which define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history.

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server.


About branch protection rules

You can enforce certain workflows or requirements before a collaborator can push changes to a branch in your repository, including merging a pull request into the branch, by creating a branch protection rule.

By default, each branch protection rule disables force pushes to the matching branches and prevents the matching branches from being deleted. You can optionally disable these restrictions and enable additional branch protection settings.

By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository. You can optionally choose to include administrators, too.

You can create a branch protection rule in a repository for a specific branch, all branches, or any branch that matches a name pattern you specify with fnmatch syntax. For example, to protect any branches containing the word release, you can create a branch rule for *release*. For more information about branch name patterns, see "Managing a branch protection rule."

About branch protection settings

For each branch protection rule, you can choose to enable or disable the following settings.

Require pull request reviews before merging

Repository administrators can require that all pull requests receive a specific number of approving reviews before someone merges the pull request into a protected branch. You can require approving reviews from people with write permissions in the repository or from a designated code owner.

If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.

If a person with admin permissions chooses the Request changes option in a review, then that person must approve the pull request before the pull request can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with write permissions for the repository can dismiss the blocking review.

Even after all required reviewers have approved a pull request, collaborators cannot merge the pull request if there are other open pull requests that have a head branch pointing to the same commit with pending or rejected reviews. Someone with write permissions must approve or dismiss the blocking review on the other pull requests first.

If a collaborator attempts to merge a pull request with pending or rejected reviews into the protected branch, the collaborator will receive an error message.

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch. ベースブランチに関する詳しい情報については「プルリクエストについて」を参照してください。

Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. 詳しい情報についてはプルリクエストレビューの却下を参照してください。

Optionally, you can choose to require reviews from code owners. If you do, any pull request that affects code with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.

Require status checks before merging

必須ステータスチェックにより、コラボレータが保護されたブランチに変更を加える前に、すべての必須 CI テストにパスしていることが保証されます。 詳細は「保護されたブランチを設定する」および「必須ステータスチェックを有効にする」を参照してください。 詳しい情報については、「ステータスチェックについて」を参照してください。

ステータスチェック必須を有効にする前に、ステータス API を使用するようにリポジトリを設定する必要があります。 For more information, see "Repositories" in the REST documentation.

After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. 必須ステータスチェックをパスしたら、コミットを別のブランチにプッシュしてから、マージするか、保護されたブランチに直接プッシュする必要があります。

注釈: リポジトリへの書き込み権限があるユーザまたはインテグレーションなら誰でも、リポジトリのステータスチェックを任意のステータスに設定できます。 GitHub は、チェックの作者が、特定の名前でチェックを作成したり、既存のステータスを変更したりする権限を持っているかを確認しません。 プルリクエストをマージする前に、マージボックスにリストされている各ステータスの作者が想定された人物であることを確認する必要があります。

必須ステータスチェックのタイプは、[loose] (寛容)、[strict] (厳格) のいずれかに設定できます。 The type of required status check you choose determines whether your branch is required to be up-to-date with the base branch before merging.

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

For troubleshooting information, see "Troubleshooting required status checks."


When you enable required commit signing on a branch, contributors can only push commits that have been signed and verified to the branch. 詳細については、「コミット署名の検証について」を参照してください。

Note: If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.

コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 However, you cannot merge pull requests into the branch on GitHub Enterprise Server. You can merge pull requests locally. 詳しい情報については、「プルリクエストをローカルでチェック アウトする」を参照してください。

Require linear history

Enforcing a linear commit history prevents collaborators from pushing merge commits to the branch. つまり、保護されたブランチにマージされたプルリクエストは、squash マージまたはリベースマージを使用する必要があります。 A strictly linear commit history can help teams reverse changes more easily. マージ方法に関する詳しい情報については「プルリクエストマージについて」を参照してください。

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

Include administrators

By default, protected branch rules do not apply to people with admin permissions to a repository. You can enable this setting to include administrators in your protected branch rules.

Restrict who can push to matching branches

When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.

You can only give push access to a protected 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.

Allow force pushes

By default, GitHub Enterprise Server blocks force pushes on all protected branches. 保護されたブランチのフォースプッシュを有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、管理者権限を持つブランチを含め、ブランチをフォースプッシュできます。

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

You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. 詳しい情報については、「ユーザアカウントもしくはOrganizationが所有するリポジトリへのフォースプッシュのブロック」を参照してください。


Allow deletions

デフォルトでは、保護されたブランチは削除できません。 When you enable deletion of a protected branch, anyone with at least write permissions to the repository can delete the branch.

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.