Errorgit
Updates were rejected, non-fast-forward
Why git rejects a push as non-fast-forward, the safe way to pull and integrate first, and when force-with-lease is appropriate instead.
Last updated
Errorgit
! [rejected] main -> main (non-fast-forward) error: failed to push some refs to 'https://github.com/user/repo.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again.
What it means: The remote branch has commits your local branch doesn't have, so git refuses to push and silently overwrite them — it wants the remote history integrated first.
Likely causes
Most probable first — with how to confirm.
- 1.Someone else — or you, from another machine — pushed commits to the same branch after your last pull; run `git fetch && git log HEAD..origin/main --oneline` to see exactly what's missing locally.
- 2.You rewrote local history (rebase or amend) and the remote still has the old commits, so the two histories have genuinely diverged rather than one simply trailing the other.
- 3.You're pushing to the wrong branch by mistake — e.g. your local branch and CI both target `main` — check `git branch -vv` for what your branch is actually tracking.
Fixes
Safest first; destructive ones are called out.
- →Pull and integrate first, then push: `git pull --rebase origin main` (keeps history linear) or `git pull origin main` (merges), resolve any conflicts, and push again — the safe default.
- →If you deliberately rewrote history and are sure no one else needs the old commits, `git push --force-with-lease` is safer than a plain `--force` because it aborts if the remote changed since your last fetch.
- →Avoid a bare `git push --force` on a shared branch without confirming with collaborators — it can discard their commits outright.
- →If you pushed to the wrong branch, check its tracking target with `git branch -vv` and point it at the right one before pushing again.