Fix a rejected push after rebasing a feature branch

A push can be rejected after a rebase because your published branch still points to the old commits. Rebase can create replacement commits with different parents and IDs, so the remote tip is no longer an ancestor of your local tip. Git rejects that non-fast-forward update to protect existing history.

For a private feature branch whose published history you intend to replace, use --force-with-lease. For shared branches, coordinate the rewrite or keep published history and merge instead.

Inspect the divergence before pushing

Replace feature with your branch name:

git fetch origin
git log --graph --oneline --left-right HEAD...origin/feature

If the remote contains only the old history you deliberately rebased, a scoped push is:

git push --force-with-lease origin HEAD:refs/heads/feature

The default lease compares the remote branch with your local remote-tracking reference. Background fetches can update that reference without you reviewing the new commits. For a stronger check, record the exact reviewed remote tip, then use it explicitly:

expected=$(git rev-parse refs/remotes/origin/feature)
# Review this remote tip and finish any required reconciliation before pushing.
git push --force-with-lease=refs/heads/feature:"$expected" \
  origin HEAD:refs/heads/feature

A lease checks whether the remote moved. It does not decide whether discarding its current history is appropriate.

Why an ordinary push fails

Before rebase:
A---B---C       feature on the remote
     \
      D        main

After rebase:
A---B---D---C'  local feature
     \
      C        remote feature

C' may contain equivalent changes, but it is a different commit. Updating the remote from C to C' cannot fast-forward. Rebase does not necessarily change every commit in the repository, and a no-op rebase may need no forced push at all.

When to avoid a forced update

Do not replace a shared main, release branch, or a teammate's work merely to make a push succeed. Protected branches may prohibit forced updates. If a rebase is still running, git rebase --abort returns to its starting point; if it is complete, use a backup branch or reflog to recover the old tip before choosing a merge-based approach.

FAQ

What must collaborators do afterward?

They must reconcile their branches with the rewritten history. A fresh branch from the new remote tip plus cherry-picked unpublished commits is one option. git reset --hard origin/feature is appropriate only when they intend to discard their local branch state and have saved any needed work.

What if force-with-lease also fails?

Fetch and inspect the remote again. A stale lease, branch protection, or server policy can reject the operation. Do not just refresh the tracking reference and repeat until it succeeds: understand and preserve any newly published work first.

Can I keep a tidy main branch without rewriting shared history?

Rebase unpublished or coordinated personal work before integration, or use your hosting service's squash-merge feature. A squash merge can produce one new commit on main without rewriting main's existing commits.

See git-push, git-rebase, and git-log.