How to fix remote: error: GH006: Protected branch update failed - required approving review in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 219 views

This error occurs when pushing to a GitHub protected branch that requires at least one approving review before changes can be merged. You must use a pull request workflow and get approval from reviewers with write access.

Quick fix

Fixes GH006

# Create a feature branch from your current work
git checkout -b feature/your-changes

# Push the feature branch to the remote
git push -u origin feature/your-changes
  1. Use the pull request workflow
  2. Check current branch protection settings
  3. Request to be added as a bypass actor
  4. Configure CI/CD with bypass permissions
git — error
# Create a feature branch from your current work
git checkout -b feature/your-changes
# Push the feature branch to the remote
git push -u origin feature/your-changes
remote: error: GH006: Protected branch update failed - required approving review

What this error means

When you see the GH006 error with "required approving review," GitHub is blocking your push because the target branch has review requirements configured. This is a core branch protection feature designed to ensure code quality through peer review. The error indicates that: - The branch has "Require a pull request before merging" enabled - At least one approving review from a reviewer with write access is required - You attempted to push directly instead of going through the pull request process This protection exists to: - Prevent unreviewed code from reaching production branches - Enforce team code review standards - Catch bugs and issues before they're merged - Maintain accountability in the codebase This error commonly appears in these scenarios: - A developer forgets they're on a protected branch and tries to push directly - CI/CD automation attempts to push version bumps or changelog updates without proper permissions - New team members aren't familiar with the repository's pull request workflow - Someone with admin privileges has "Do not allow bypassing the above settings" enabled

Typical symptoms

  • Git push fails with 'GH006: Protected branch update failed' and mentions 'approving review'
  • Error message states 'At least 1 approving review is required by reviewers with write access'
  • Push to main, master, or other protected branch is rejected
  • CI/CD pipeline fails during push step with branch protection error
  • Force push is also rejected on the protected branch
  • Previously working push commands now fail after branch protection was enabled

Common causes

  1. Attempting to push directly to a protected branch that requires pull request reviews (most common)
  2. Branch protection rule 'Require a pull request before merging' is enabled with review requirements
  3. User account is not listed in 'Allow specified actors to bypass required pull requests'
  4. GitHub Actions workflow using default GITHUB_TOKEN which cannot bypass review requirements
  5. Personal access token (PAT) lacks sufficient permissions or is not configured as a bypass actor
  6. 'Do not allow bypassing the above settings' is enabled, blocking even admins
  7. Code owner review is required and you are the code owner (cannot self-approve)

How to fix "remote: error: GH006: Protected branch update failed - required approving review"

1Use the pull request workflow

The correct approach is to create a pull request and get it reviewed:

bash
# Create a feature branch from your current work
git checkout -b feature/your-changes

# Push the feature branch to the remote
git push -u origin feature/your-changes

Then on GitHub:
1. Open a pull request from your feature branch to the protected branch
2. Request a review from a team member with write access
3. Address any feedback and get approval
4. Merge the pull request through the GitHub interface

This is the intended workflow and should be the default approach.

2Check current branch protection settings

If you have repository access, review what's configured:

1. Go to your repository on GitHub
2. Navigate to Settings > Branches
3. Under "Branch protection rules," find your branch rule
4. Click Edit to see the current settings

Look for these settings:
- Require a pull request before merging - Must use PRs
- Require approvals - Number of reviews needed (e.g., 1 or 2)
- Require review from Code Owners - CODEOWNERS file reviewers must approve
- Dismiss stale pull request approvals - New commits require re-review
- Do not allow bypassing the above settings - Even admins can't bypass

3Request to be added as a bypass actor

If your workflow legitimately requires direct push access (rare):

1. Ask a repository admin to go to Settings > Branches
2. Edit the branch protection rule
3. Under "Allow specified actors to bypass required pull requests"
4. Add your GitHub username, team, or GitHub App
5. Save the changes

Important considerations:
- Only request this if you have a legitimate need (e.g., release automation)
- This weakens code review protections
- Consider using a dedicated service account instead of your personal account
- Document why bypass access was granted

4Configure CI/CD with bypass permissions

For automated workflows that need to push to protected branches:

Option 1: Use a Personal Access Token (PAT)

1. Create a PAT with repo scope at GitHub Settings > Developer settings > Personal access tokens
2. Add the PAT owner to the bypass actors list
3. Add the PAT as a repository secret (e.g., BUILD_PAT)
4. Update your GitHub Actions workflow:

yaml
- uses: actions/checkout@v4
  with:
    token: ${{ secrets.BUILD_PAT }}

- name: Configure git
  run: |
    git config user.name "github-actions[bot]"
    git config user.email "github-actions[bot]@users.noreply.github.com"

Option 2: Create a GitHub App

1. Create a GitHub App with contents: write permission
2. Install the app on your repository
3. Add the app to the bypass actors list
4. Use the app's installation token in workflows

5Use GitHub Rulesets for more flexibility

GitHub Rulesets provide more granular control than classic branch protection:

1. Go to Settings > Rules > Rulesets
2. Create a new ruleset or convert existing branch protection
3. Under "Bypass list," configure who can bypass:
 - Repository admins
 - Specific teams or users
 - GitHub Apps
 - Deploy keys

Rulesets advantages:
- Can apply to multiple branches with patterns
- GitHub Apps can be added to bypass list (not possible with classic protection)
- Can be applied at organization level
- More intuitive bypass configuration

6Handle the 'cannot approve your own pull request' case

If you're a code owner and cannot get someone else to review:

Scenario: You own a file, made changes, but need approval from a code owner (yourself).

Solutions:

1. Add another code owner: Update the CODEOWNERS file to include another team member for those paths

2. Request a non-code-owner review: If "Require review from Code Owners" is not checked, any reviewer with write access can approve

3. Temporary code owner change: Have an admin temporarily modify CODEOWNERS to allow someone else to approve

4. Admin bypass: If urgent, an admin can:
 - Temporarily disable "Require review from Code Owners"
 - Merge the PR
 - Re-enable the setting

bash
# Check current CODEOWNERS file
cat .github/CODEOWNERS

Advanced notes

### Why the Default GITHUB_TOKEN Cannot Bypass Reviews

The GITHUB_TOKEN automatically provided to GitHub Actions intentionally cannot bypass branch protection rules. This is a security feature—if it could, a compromised workflow could push malicious code directly to protected branches, defeating the purpose of protection.

To allow automation to push to protected branches, you must use:
- A Personal Access Token (PAT) from a user with bypass permissions
- A GitHub App installation token with bypass permissions
- A deploy key (for limited scenarios)

### Organization-Level Considerations

If your repository is part of a GitHub organization:

1. Bypass actors can only be added in organizations - Personal repositories don't support the bypass actors feature in classic branch protection
2. Organization admins can enforce rules - Some settings may be locked at the organization level
3. Rulesets can be organization-wide - Allowing centralized management of bypass permissions

### Dismiss Stale Approvals

If "Dismiss stale pull request approvals when new commits are pushed" is enabled:
- Any new commit after approval requires re-review
- This can block automation that pushes additional commits after initial approval
- Consider having automation push all changes before requesting review

### Required Reviewers vs Required Reviews

- Required reviews: Any N reviewers with write access can approve
- Required reviewers from Code Owners: Specific people defined in CODEOWNERS must approve
- Both can be enabled simultaneously, requiring both conditions to be met

### Emergency Situations

If you absolutely need to push and cannot wait for review:
1. Contact a repository admin
2. They can temporarily disable the review requirement
3. Push your changes
4. Re-enable the protection immediately
5. Create a post-hoc review issue to document the bypass

Never leave protection disabled - this creates a security window.

Frequently asked questions

What does "GH006" mean?
When you see the GH006 error with "required approving review," GitHub is blocking your push because the target branch has review requirements configured. This is a core branch protection feature designed to ensure code quality through peer review.
How do I fix "GH006"?
This error occurs when pushing to a GitHub protected branch that requires at least one approving review before changes can be merged. You must use a pull request workflow and get approval from reviewers with write access.
What causes "GH006"?
Attempting to push directly to a protected branch that requires pull request reviews (most common) Branch protection rule 'Require a pull request before merging' is enabled with review requirements User account is not listed in 'Allow specified actors to bypass required pull requests'
Is the "GH006" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading