Fix a push rejected as non-fast-forward

Does this match your situation?

• '! [rejected] main -> main (non-fast-forward)' or '(fetch first)'.
• 'Updates were rejected because the remote contains work that you do not have locally.'
• A teammate pushed while you were working.
• You amended or rebased commits that were already pushed.

Step-by-step fix

1. See what the server has that you don't

   Fetch first - it downloads their commits without touching your files, so you can look before deciding anything. This is always safe and always the right first move.

   step 1Copy

   git fetch origin
   git log --oneline HEAD..origin/main    # their commits you're missing
   git log --oneline origin/main..HEAD    # your commits they're missing
   

2. Integrate their work, then push

   Rebase replays your commits on top of theirs for a clean linear history. Merge keeps both histories and adds a merge commit. Either works; rebase is the usual choice for a feature branch that only you are on.

   step 2Copy

   git pull --rebase origin main
   # resolve any conflicts, then:
   git push
   

   ✅If the rebase hits a conflict, fix the files, git add them, then git rebase --continue.

3. Or merge instead, if the branch is shared

   When several people work on the same branch, rebasing rewrites commits they already have. Merging is the safer integration in that situation.

   step 3Copy

   git pull --no-rebase origin main
   git push
   

4. Only force-push if you deliberately rewrote history

   If you amended, squashed or rebased commits that were already pushed, the rejection is expected and correct — you really do want to replace the remote branch. Use --force-with-lease so the push aborts if someone else pushed in the meantime.

   step 4Copy

   git push --force-with-lease
   

   🚨Never force-push a branch other people work on without telling them. On main, don't force-push at all.

Why this works

A push is only allowed to move a remote branch forward along its own history — a 'fast-forward'. If the server's branch contains commits that aren't ancestors of what you're pushing, moving the pointer would orphan them, so Git refuses. That rejection is the single most valuable safety check Git has: it is the reason accidental data loss on shared branches is rare. Pulling makes their commits ancestors of yours, which restores the fast-forward relationship and lets the push through.

How to stop it happening again

• Run git pull --rebase before you start work each day, and again before pushing.
• Set it as the default: git config --global pull.rebase true.
• Push small changes often — the longer you wait, the more divergence you accumulate.
• Never amend or rebase commits that have already been pushed to a shared branch.

Commands used in this guide

Frequently asked questions