git push_error ai_generated true

remote rejected — force push denied by server-side hooks or branch protection

ID: git/push-force-rejected

Also available as: JSON · Markdown
82%Fix Rate
90%Confidence
90Evidence
2017-01-01First Seen

Version Compatibility

VersionStatusIntroducedDeprecatedNotes
2 active — — —

Root Cause

Force pushes are rejected by server-side branch protection rules, pre-receive hooks, or repository settings. This is a safety feature to prevent history rewriting on shared branches. The solution depends on whether you actually need to force push (after rebase) or should be using merge-based workflows instead.

generic

Workarounds

  1. 90% success Use git push --force-with-lease instead of --force 
    Run 'git push --force-with-lease' instead of '--force'. This checks that the remote branch hasn't been updated since your last fetch. If someone else has pushed, it fails safely. This is the recommended way to push after rebase on feature branches.

    Sources: https://git-scm.com/docs/git-push

  2. 95% success Use merge workflow instead of rebase for shared branches 
    Instead of rebasing and force pushing, use 'git merge main' into your feature branch. Merge commits preserve existing history and allow normal (fast-forward or merge) pushes. For main branch: use 'git merge --no-ff feature-branch' to keep the feature branch history intact.

    Sources: https://git-scm.com/docs/git-merge

  3. 92% success Push to a new branch if force push to protected branch is needed 
    Instead of force pushing to the protected branch, push to a new branch: 'git push origin HEAD:my-branch-v2'. Then create a new PR from this branch. This preserves the original branch history and avoids needing admin privileges.

Dead Ends

Common approaches that don't work:

  1. Using git push --force to overwrite protected branch history 99% fail

    Protected branches on GitHub/GitLab/Bitbucket explicitly block force pushes to prevent history loss on shared branches. No amount of --force flags will override server-side protection. The protection must be modified by a repository admin, or you must push to a different branch.

  2. Force pushing to main/master after a local rebase 95% fail

    Rebasing rewrites commit history (new hashes). Force pushing this to main overwrites what other developers have based their work on, causing everyone else's branches to diverge catastrophically. This is the single most destructive common git operation in team settings.

  3. Using --force instead of --force-with-lease 60% fail

    --force unconditionally overwrites the remote branch, even if someone else pushed new commits since your last fetch. This silently drops their work. --force-with-lease is safer because it fails if the remote has changed since your last fetch, preventing accidental overwrites.

Error Chain

Preceded by:
Frequently confused with: