GitHub · Pull requests · Branch protection · Checked October 30, 2026

GitHub: "GH006: Protected branch update failed" and "GH013: Repository rule violations found"

When a push to a branch does not meet the rules that protect it, GitHub refuses the push and Git prints the answer on lines that start with remote:. With branch protection, the first line is GH006 and the next one gives the reason (GitHub: About protected branches, checked October 30, 2026). With rulesets, it is GH013, as in "GH013: Repository rule violations found for refs/heads/main" (GitHub: Troubleshooting your migration with GitHub Enterprise Importer).

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

Rules that refuse a direct push

Require a pull request before merging (rulesets): all changes to the target branch must be associated with a pull request. The pull request does not have to be approved, but it must be opened (GitHub: Available rules for rulesets). In the REST API it is the rule pull_request. The message "Changes must be made through a pull request." is among the API errors in the tests of the GitHub MCP server (github/github-mcp-server).
Require a pull request before merging (branch protection): under "Protect matching branches" in a branch protection rule. With required approvals, collaborators can only push changes to the protected branch via a pull request that is approved by the required number of reviewers with write permissions (GitHub: Managing a branch protection rule, About protected branches).
Restrict updates, Restrict who can push: the ruleset rule Restrict updates (update) lets only users with bypass permissions push to matching branches. In branch protection, Restrict who can push to matching branches lets only the users, teams or apps given permission push, and they still need to create a pull request when pull requests are required.
Required status checks: before the required checks have passed, a push to the protected branch is refused with GH006 (see a required check stuck at "Expected").
A merge commit made locally: with Dismiss stale pull request approvals when new commits are pushed or Require approval of the most recent reviewable push, manually creating the merge commit for a pull request and pushing it directly to the protected branch fails, unless the contents of the merge exactly match the merge GitHub generates for the pull request.

Who can still push

Admins, with branch protection: by default, the restrictions of a branch protection rule do not apply to people with admin permissions to the repository or to custom roles with the "bypass branch protections" permission. Do not allow bypassing the above settings applies them to those people too.
Chosen actors, with branch protection: Allow specified actors to bypass required pull requests lets the selected actors push code to the branch without creating pull requests.
The bypass list, with rulesets: repository admins, organization and enterprise owners, the maintain or write role, teams, GitHub Apps and Dependabot can be granted bypass. An actor set to For pull requests only (bypass_mode: pull_request in the REST API) is required to open a pull request to make changes, and can then bypass the branch protections to merge it, so being on the bypass list does not always allow a direct push (GitHub: Creating rulesets for a repository, REST API endpoints for rules).

What to do

Move the commits to a new branch and open a pull request: on the branch whose push was refused, create a branch at the same commit and push that one instead:
```
git switch -c fix-login
git push -u origin fix-login
```
Then open a pull request with the protected branch as the base and the new branch as the compare branch; on the repository page, choose the branch, then Compare & pull request above the list of files (GitHub: Creating a pull request). Your local main still points at the refused commits; the main on GitHub gets them when the pull request is merged.
Find the rule: on the Rulesets page, anyone with read access can view the active rulesets that target a branch, and in the repository settings, Rules then Insights shows the actions checked against rulesets that passed, failed or were bypassed (GitHub: Managing rulesets for a repository). The REST endpoint Get rules for a branch returns every active rule for a branch name, from the repository or the organization, also for a branch that does not exist yet (GitHub: REST API endpoints for rules).
Merge on GitHub, not locally: instead of pushing a merge commit you made yourself, merge the pull request on GitHub.
If the push really has to go straight to the branch: ask an admin to add you to Allow specified actors to bypass required pull requests, or to the ruleset bypass list with Always allow.

In IntelliJ IDEA: "rejected by the remote", without GitHub's reason

How the Git and GitHub support built into IntelliJ IDEA deal with a push GitHub refuses, in its source (checked November 1, 2026; IntelliJ IDEA: GitPushOperation.java, GitPushNativeResultParser.java, GitPushNativeResult.java, GitPushRepoResult.java, GitPushResultNotification.java, GitBundle.properties, VcsNotifier.java, GitPusher.kt, GHPushNotificationCustomizer.kt, GHPRCreatePullRequestAction.kt, GithubBundle.properties):

A refused branch: the IDE reads Git's answer to the push, one line per branch with a flag and a reason in parentheses. A branch flagged ! counts as rejected by the remote unless the reason says non-fast-forward, fetch first, failed to lock or stale info. In a project with one repository the notification is then titled "Push rejected", and its text is built from the branch names only, as in "Push main to origin/main was rejected by the remote": the reason Git gave is kept with the result but not used in that text, so the GH006 or GH013 lines are not in it.
No answer per branch: when Git's output has no such line for any branch, the push counts as failed, the notification is titled "Push failed" (with one repository), and its text is Git's error output. In both cases, when the VCS console is not empty, the notification also has "Show details in console", which opens the console tab and scrolls to its end.
No pull request offer on a refusal: after a push, the GitHub support adds an action to the notification only for a branch that was pushed successfully, in a GitHub repository the IDE has an account for, and that is not the repository's default branch on GitHub: "Create pull request" when it finds no open pull request from that branch, "View pull request" when it finds exactly one. A refused branch gets neither.
After moving the commits to a new branch: pushing that branch can therefore give a notification with "Create pull request", which starts the IDE's own new pull request flow. How that flow picks the base branch and decides whether to push: GitHub: why the branch was not found. Which branches the Push dialog keeps from force pushes: GitHub: a force push is blocked.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff. The plugin does not push. Once you are on the new branch, it creates the pull request from the branch you have checked out into the protected branch, offering the target from the repository's branches on GitHub as you type; when the branch is not on GitHub yet, it says so and opens the IDE's push dialog. The pull request is then merged on GitHub with the methods the target branch allows. The review inbox, diffs and conversations are free; creating pull requests, approving, commenting and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.