Skip to main content
설명서에 자주 업데이트를 게시하며 이 페이지의 번역이 계속 진행 중일 수 있습니다. 최신 정보는 영어 설명서를 참조하세요.

이 버전의 GitHub Enterprise는 다음 날짜에 중단됩니다. 2023-03-15. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 성능 향상, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

보호된 분기 정보

공동 작업자가 푸시를 삭제하거나 분기로 강제 적용할 수 있는지 여부를 정의하는 분기 보호 규칙을 설정하여 중요한 분기를 보호할 수 있으며 상태 검사 또는 선형 커밋 기록 전달과 같은 분기에 대한 푸시 요구 사항을 설정할 수 있습니다.

보호된 분기는 GitHub Free 및 조직에 대한 GitHub Free가 있는 퍼블릭 리포지토리와 GitHub Pro, GitHub Team, GitHub Enterprise Cloud, 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."

You can configure a pull request to merge automatically when all merge requirements are met. For more information, see "Automatically merging a pull request."

About branch protection settings

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

For more information on how to set up branch protection, see "Managing a branch protection rule."

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. For information about the base branch, see "About pull requests."

Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "Dismissing a pull request review."

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

Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch. Required status checks can be checks or statuses. For more information, see "About status checks."

Before you can enable required status checks, you must configure the repository to use the commit status API. For more information, see "Commit statuses" in the REST API documentation.

After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.

Any person or integration with write permissions to a repository can set the state of any status check in the repository, but in some cases you may only want to accept a status check from a specific GitHub App. When you add a required status check, you can select an app that has recently set this check as the expected source of status updates. 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.

You can set up required status checks to either be "loose" or "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.

Type of required status checkSettingMerge requirementsConsiderations
StrictThe Require branches to be up to date before merging checkbox is checked.The branch must be up to date with the base branch before merging.This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.
LooseThe Require branches to be up to date before merging checkbox is not checked.The branch does not have to be up to date with the base branch before merging.You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch.
DisabledThe Require status checks to pass before merging checkbox is not checked.The branch has no merge restrictions.If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.

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

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.

Require signed commits

When you enable required commit signing on a branch, contributors can only push commits that have been signed and verified to the branch. For more information, see "About commit signature verification."

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.

You can always push local commits to the branch if the commits are signed and verified. However, you cannot merge pull requests into the branch on GitHub Enterprise Server. You can merge pull requests locally. For more information, see "Checking out pull requests locally."

Require linear history

Enforcing a linear commit history prevents collaborators from pushing merge commits to the branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams reverse changes more easily. For more information about merge methods, see "About pull request merges."

Before you can require a linear commit history, your repository must allow squash merging or rebase merging. For more information, see "Configuring pull request merges."

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.

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. 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.

Allow force pushes

By default, GitHub Enterprise Server blocks force pushes on all protected branches. When you enable force pushes to a protected branch, you can choose one of two groups who can force push:

  1. Allow everyone with at least write permissions to the repository to force push to the branch, including those with admin permissions.
  2. Allow only specific people or teams to force push to the branch.

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.

Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.

You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "Blocking force pushes to repositories owned by a personal account or organization."

If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.

Allow deletions

By default, you cannot delete a protected branch. When you enable deletion of a protected branch, anyone with at least write permissions to the repository can delete the branch.