This error occurs when you attempt to force push to a branch that GitLab has marked as protected. Protected branches prevent history rewriting to maintain code integrity and require specific permissions or configuration changes to allow force pushes.
GitLab's protected branches feature prevents destructive operations like force pushes, deletions, and unreviewed direct pushes to important branches. When you run `git push --force` or `git push -f` to a protected branch, GitLab's server-side hooks reject the push with this error. Force pushing rewrites Git history by replacing commits on the remote with your local commits, discarding any commits that existed only on the remote. This is dangerous on shared branches because: - Other developers may lose work if they've based commits on the overwritten history - CI/CD pipelines may fail or produce inconsistent results - Audit trails and blame history become unreliable By default, GitLab protects the `main` (or `master`) branch from force pushes. Maintainers and administrators can configure which branches are protected and what operations are allowed.
First, confirm that the branch you're pushing to is protected:
1. Go to your GitLab project
2. Navigate to Settings > Repository
3. Expand Protected branches
4. Look for your branch (e.g., main, master) in the list
If the branch appears in the list, it's protected and force pushes are blocked by default.
If you have Maintainer or Owner role and need to enable force push:
1. Go to Settings > Repository > Protected branches
2. Find the protected branch you need to modify
3. Click Unprotect to remove protection, or
4. Click the branch name to edit settings
5. Toggle Allowed to force push to enable force pushes for specific roles
Note: You need at least Maintainer role to change protected branch settings.
For GitLab Premium/Ultimate:
You can set granular permissions allowing only certain users or groups to force push while keeping the branch protected for others.
Instead of force pushing, consider safer alternatives:
Option A: Create a new branch and merge
git checkout -b fix-branch
git push origin fix-branch
# Create a merge request in GitLabOption B: Revert commits instead of rewriting history
git revert <commit-hash>
git push origin mainOption C: Use `--force-with-lease` (still blocked on protected branches, but safer)
git push --force-with-lease origin mainThis only forces if the remote hasn't changed since you last fetched, preventing accidental overwrites.
If you must force push (e.g., removing sensitive data from history):
1. Go to Settings > Repository > Protected branches
2. Click Unprotect next to the branch
3. Perform your force push:
git push --force origin main4. Immediately re-protect the branch by clicking Protect and configuring the original settings
Warning: While the branch is unprotected, anyone with push access can force push or delete it. Keep the unprotected window as short as possible.
If you can't find protection settings at the project level, check higher-level settings:
Group-level protected branches (GitLab Premium):
1. Go to your group
2. Navigate to Settings > Repository > Protected branches
3. Group-level protections override project settings
Instance-level (GitLab administrators only):
- Contact your GitLab administrator
- Instance-wide push rules may block force pushes across all projects
Push rules (GitLab Premium):
1. Check Settings > Repository > Push rules
2. Look for "Reject unsigned commits" or custom rules that might block your push
If you don't have permission to modify protected branch settings:
1. Contact a project Maintainer or Owner
2. Explain why you need to force push (e.g., removing secrets, fixing corrupted history)
3. Ask them to either:
- Temporarily unprotect the branch while you push
- Perform the force push on your behalf
- Add you to the allowed force push list (Premium feature)
For compliance-sensitive projects, you may need to create a merge request documenting the history change instead.
### Why Protected Branches Exist
Protected branches are a critical Git workflow safeguard. They:
- Prevent accidental deletion of important branches
- Ensure code review via merge requests
- Maintain linear, auditable commit history
- Protect against malicious history tampering
For most teams, enabling force push on protected branches defeats the purpose of protection. Consider whether you truly need to force push or if an alternative workflow is better.
### Removing Sensitive Data
If you need to force push to remove secrets or sensitive data from Git history:
1. Use git filter-branch or BFG Repo Cleaner to rewrite history locally
2. Coordinate with your teamโeveryone will need to re-clone or reset their local copies
3. Temporarily unprotect the branch, force push, then re-protect
4. Rotate any exposed credentials immediately
5. Consider GitLab's housekeeping to clean up old objects
### Force Push in CI/CD Pipelines
If your CI/CD pipeline needs to force push (e.g., for GitOps or automated releases):
1. Use a deploy token or project access token with appropriate permissions
2. Configure the protected branch to allow force push from the CI/CD service account
3. Consider using --force-with-lease to prevent race conditions
### Branch Protection Wildcards
GitLab supports wildcard patterns for protected branches:
- release/* protects all release branches
- *-stable protects branches ending in -stable
Check if your branch matches a wildcard pattern in protected branch settings.
### GitLab vs GitHub
This error is GitLab-specific. GitHub has similar branch protection but uses different terminology and UI. If you're seeing this on GitHub, look for "branch protection rules" in repository settings.
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git
fatal: unable to access: no_proxy configuration not working
How to fix 'no_proxy configuration not working' in Git
fatal: unable to read tree object in treeless clone
How to fix 'unable to read tree object in treeless clone' in Git