Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

When Git says “Updates were rejected,” don’t force-push as a first response. Read the full error, fetch the intended remote branch, integrate its commits with your local work using a merge or rebase, then push again. That preserves both sides’ history in the usual non-fast-forward case. Other server-side rejections need a different fix.

What “Updates were rejected” means

A normal Git branch push must be a fast-forward: the remote branch’s current tip must already be an ancestor of the commit you’re pushing. If someone pushed while you were working, the remote may contain commits missing from your local branch. Pushing your branch as-is could make those remote commits unreachable from that branch, so Git refuses rather than silently discarding them. The Git project’s git-push manual describes the safe remedy: fetch the remote history, create a history containing both sides’ work, and push that result.

The short message alone does not prove that the problem is a non-fast-forward update. Check the complete terminal output before choosing a fix.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Safely integrate the remote work and push

First confirm which branch you are on and which remote branch it tracks. The examples below assume the remote is named origin; replace it if your repository uses another name. Replace <branch> with the actual upstream branch.

git status
git branch -vv
git fetch origin
git log --oneline --graph --decorate --all

These commands show your working-tree state, branch tracking information, fetched remote updates, and a compact view of the available history. Once you have confirmed the correct upstream, choose one integration method:

git merge origin/<branch>

Or, if your team’s workflow calls for rebasing:

git rebase origin/<branch>

After the merge or rebase has completed, retry the push:

git push

git pull can fetch and integrate in one step, but check that the current branch tracks the remote branch you intend to update. The git-pull documentation explains that pull fetches first and then integrates the selected upstream. Choosing merge or rebase explicitly makes the integration method clear.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose merge or rebase

Method What happens When it may fit
Merge Combines the histories and, when they have diverged, records their join with a merge commit. When you want to retain the published commit topology or your team follows a merge-based workflow.
Rebase Replays your local commits on top of the updated remote history, creating new commit IDs for those replayed commits. When your local commits are suitable for replay and your team prefers a linear history. Avoid rebasing commits others already depend on unless the team agrees.

Both are documented ways to integrate the two sides before pushing. The rejection itself does not tell you which method your project prefers; follow the team’s convention.

If Git reports conflicts

A conflict means Git cannot automatically combine some changes. Review each conflicted file, edit it to contain the intended result, and complete the operation you started. If you decide not to continue, Git documents git merge --abort for a merge and git rebase --abort for a rebase. Do not retry the push until the integration has been completed.

If the message is not a non-fast-forward rejection

Git distinguishes a client-side rejected update from a remote rejected update. A remote rejection can come from a server-side hook or repository policy, including settings such as receive.denyNonFastForwards, receive.denyCurrentBranch, or deletion policies. Read the full status and reason. If it names a policy, permission, or hook, address that issue or ask the repository administrator; merging remote history alone may not solve it.

Why force-pushing is not the routine fix

Git’s push manual warns that --force disables safety checks and can cause remote commits to be lost. Use it only when replacing published history is intentional and affected collaborators have agreed. --force-with-lease checks an expected remote value, but the manual also warns that its shorthand can interact badly with background fetches that update remote-tracking references. Neither option is needed when the goal is simply to preserve both local and remote work.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

If the remote changes again before your push

Another push may advance the remote after you fetch and integrate. If your push is rejected again for being non-fast-forward, fetch the newer commits, integrate them using the agreed merge or rebase workflow, and retry. The rejection is protecting that newer remote work from being silently dropped.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.