git push rejected — non-fast-forward / updates were rejected
Git
failed to push some refs to '...' / Updates were rejected because the remote contains work that you do not have locally.
What it means (root cause)
The remote branch has commits you don't have (someone else pushed, or you pushed from another machine). A non-fast-forward push is rejected to avoid overwriting history.
The symptom developers actually see: failed to push some refs to '...' / Updates were rejected because the remote contains work that you do not have locally.
Step-by-step fix
Concrete, ordered steps from the dataset. Apply them in order; each line is a verified action, not generic advice.
- 1Fetch and integrate first: git pull --rebase origin <branch> (rebase keeps a linear history).
- 2Resolve any conflicts, then git push again.
- 3Only force with git push --force-with-lease after confirming you intend to rewrite shared history.
Where this error appears
Languages, frameworks, and runtimes where this error is observed (from the 2026 DevFixPro error dataset, retrieved 2026-08-29):
Any Git remote (GitHub/GitLab). --force-with-lease is safer than --force on shared branches.
How to prevent it & common questions
Practical prevention plus the questions developers ask most about this error.
What does "git push rejected — non-fast-forward / updates were rejected" mean?
The remote branch has commits you don't have (someone else pushed, or you pushed from another machine). A non-fast-forward push is rejected to avoid overwriting history.
Which environments are affected by git push rejected — non-fast-forward / updates were rejected?
Git
How do I fix git push rejected — non-fast-forward / updates were rejected?
Fetch and integrate first: git pull --rebase origin <branch> (rebase keeps a linear history). Resolve any conflicts, then git push again. Only force with git push --force-with-lease after confirming you intend to rewrite shared history.
How do I prevent git push rejected — non-fast-forward / updates were rejected?
Pull/rebase before pushing; on shared branches avoid plain --force (use --force-with-lease).
pull --rebase or pull --merge?
Rebase keeps history linear and is preferred for feature branches; merge creates a merge commit. Both integrate the remote commits you were missing.
When is --force-with-lease acceptable?
Only when you deliberately rewrite shared history and have confirmed no one else pushed since your last fetch. It refuses if the remote moved unexpectedly.
Related DevFixPro tools
Real, browser-only utilities on DevFixPro that help while you work through this issue. These are navigation aids, not a substitute for the fix above.
Sources & attribution
- Error records aggregated from Google Search Console query gaps (2026-05-21~2026-08-18) for devfixpro.com, plus official framework docs (MDN, Node.js docs, Python docs, Go.dev, Rust book, Oracle Java docs, Docker docs, npm docs). Source dataset retrieved 2026-08-29. License: CC BY 4.0 — attribute DevFixPro (devfixpro.com).
- Official reference: https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches
- All cause, environment, fix and prevention text on this page is taken verbatim from the DevFixPro 2026 error dataset. DevFixPro does not invent root causes or fixes.
How this git push rejected — non-fast-forward / updates were rejected page is built
Each error page is generated from a single record in the DevFixPro 2026 error dataset. The meaning, root cause, environments, fix steps, prevention, and official references are copied verbatim from that dataset and its official-doc sources; related-error links are computed from the error's category and explicit peer list. No root cause or fix is invented. The retrieval date for this dataset is 2026-08-29.