AI Diagnostic Summary

Git Push Rejected: Updates Were Rejected (Non-Fast-Forward)

Well-Documented Error

This error matches known, documented patterns with reliable solutions.

Quick Fix (Most Common Solution)

Pull the remote changes: git pull origin [branch-name]
Resolve any merge conflicts if they appear

Seeing "! [rejected] main -> main (non-fast-forward)"? This error can be frustrating, but it's usually fixable. It typically affects your development workflow or system. Below you'll find clear, step-by-step solutions to resolve this issue.

High confidence

What This Error Means

Your local branch is behind the remote. Someone else pushed commits to the same branch since your last pull, and git refuses to overwrite their work. You must integrate the remote commits into your branch before pushing.

Frequently documented in developer and vendor support forums.

Based on documented solutions and common real-world fixes.
Not affiliated with browser, OS, or device manufacturers.

New here? Learn why exact error messages matter →

Common Causes

Another developer pushed commits to the same branch after your last pull
You amended or reset commits locally that had already been pushed to the remote
You pushed from one machine but are now working on another without pulling

How to Fix

Pull the remote changes: git pull origin [branch-name]
Resolve any merge conflicts if they appear
Push again: git push origin [branch-name]

Last reviewed: June 2026 How we review solutions

Didn't fix it? Get a personalised solution

Environment-Specific Commands

Standard fix — pull then push

git pull origin [branch-name]
# Resolve any merge conflicts if they appear
git push origin [branch-name]

Rebase approach (linear history)

git pull --rebase origin [branch-name]
# If conflicts: resolve, then git rebase --continue
git push origin [branch-name]

Quick Diagnostic Path

If You recently ran git reset or amend on a commit that was already pushed → Use git push --force-with-lease (safer than --force — fails if someone else pushed in the meantime)
If git pull produced merge conflicts → Resolve conflicts, git add the files, git commit, then git push
If Rejected on a protected branch (main/develop) → Create a feature branch, push it, and open a pull request instead

If This Still Fails, Check

--force-with-lease vs --force: --force-with-lease fails if someone else pushed since your last fetch, making it significantly safer for shared branches
Diverged histories after rebase: if you rebased a branch others have checked out, they will need to git pull --rebase or reset their local branch
GitHub branch protection: even --force may be blocked by repository protection rules — check Settings > Branches in the repository

Pull, integrate remote commits, and push

# See what is on the remote that you do not have
git fetch origin
git log HEAD..origin/[branch-name] --oneline

# Option 1: merge approach
git pull origin [branch-name]

# Option 2: rebase approach (linear history)
git pull --rebase origin [branch-name]
# If conflicts appear: resolve, git add, then:
# git rebase --continue

# Push
git push origin [branch-name]

# Verify
git log --oneline -5

OS-Specific Behavior

Line Endings and Push Rejected Non Fast Forward Across Windows, macOS, and Linux

Line ending mismatches are a persistent source of Push Rejected Non Fast Forward in cross-platform teams. Windows uses CRLF (\r\n), Linux and macOS use LF (\n). Without coordination, every file shows as modified after checkout on a different OS. The authoritative fix is a .gitattributes file committed to the repository root: * text=auto normalizes all text files to LF in the repository and converts to the platform's line ending on checkout. For shell scripts and executables that must always have LF (even on Windows), use *.sh text eol=lf. For files that should always have CRLF (Windows batch scripts), use *.bat text eol=crlf. Git's core.autocrlf setting is an alternative but is per-machine rather than per-repository — committing .gitattributes enforces consistency for the whole team regardless of individual settings. After adding .gitattributes, normalize existing files with git add --renormalize . to fix line endings in the index without modifying working tree files.

Optional follow-up

Some users ask whether saving fixes for recurring errors would be useful when the same issue appears again.

Was this explanation helpful?

Explanations are based on documented fixes, real-world reports, and common system behavior. GetErrorHelp is independent and not affiliated with software vendors, device manufacturers, or service providers.

Frequently Asked Questions

What is the difference between git pull and git pull --rebase?

git pull creates a merge commit. git pull --rebase replays your local commits on top of the remote commits, producing a linear history. Use --rebase on feature branches to keep history clean.

When is git push --force acceptable?

Only on your own personal feature branches where you are the sole contributor and you know exactly what you are overwriting. Never use --force on main, develop, or any shared branch.

Why does this happen even when I am the only developer?

If you committed via the GitHub/GitLab web UI, or pushed from a different machine, those commits exist on the remote but not locally. git pull fetches and integrates them.

Related Resources

Also Known As

Git error
Version control error
Git command failure
Repository error

Common Search Variations

"git push rejected fix"
"git merge conflict how to resolve"
"git error what to do"
"git command failed"
"fix git repository error"
"git authentication failed solution"

Related Errors

Still Stuck?

Paste a different error message or upload a screenshot to get help instantly.

Solutions are based on commonly documented fixes and may not apply in all situations.