What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When Git says “Updates were rejected,” first read the complete error. If it is a non-fast-forward rejection, fetch the remote branch, integrate its commits with your local work using a merge or rebase, then push again. That preserves both sides’ history without force-pushing. Other rejection causes—such as a server hook or permission rule—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 are pushing. If someone else pushed while you were working, the remote may contain commits missing from your local branch. Pushing without integrating them would make the remote history unsafe to replace, so Git refuses.
As an Amazon Associate I earn from qualifying purchases.
The Git project’s git-push documentation describes the safe remedy: fetch the remote history, create a history containing both sides’ work, and push that result. The message may also say “fetch first,” “non-fast-forward,” or “remote contains work that you do not have locally”; exact wording varies. Diagnose from the full output, not the short phrase alone.
Safely integrate the remote changes and push
These example commands assume the remote is named origin and that you know the branch you intend to update. Replace <branch> with its actual name.
#1 Best Overall
-
Check your current state and tracking branch:
git status git branch -vvConfirm that you are on the intended branch and identify its upstream. If the tracking information is missing or points elsewhere, do not blindly pull; verify the correct remote branch first.
-
Fetch the remote without changing your working branch:
Rank #2
git fetch origin -
Inspect how the local and remote histories relate:
git log --oneline --graph --decorate --allThen integrate the correct upstream branch using one of the approaches below:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsSpecial offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.git merge origin/<branch>Or, if your team uses rebase for this branch:
git rebase origin/<branch> -
If Git reports conflicts, edit the conflicted files to make the intended combined changes, then complete the merge or rebase. If you need to abandon the operation instead, use the matching abort command:
git merge --abortFor a rebase, use:
git rebase --abort -
After the integration finishes successfully, push again:
git pushIf the remote branch advances again before your push, fetch and integrate those newer commits too.
git pull combines fetching with integration. The Git project’s git-pull documentation explains that it fetches and then integrates the selected upstream branch. If you use pull, ensure the upstream is correct and choose the merge or rebase behavior your project expects.
Choose merge or rebase
| Approach | What it does | When it may fit |
|---|---|---|
| Merge | Combines the remote and local histories; when they have diverged, it records their join with a merge commit. | When preserving existing published commit topology or following a merge-based team workflow. |
| Rebase | Replays local commits on top of the updated remote history, creating new commit IDs for the replayed commits. | When the local commits are appropriate to replay and the team prefers a linear history. Avoid rebasing commits other people already depend on unless the team agrees. |
Both are valid integration paths. The rejection message does not determine which your project should use; follow its conventions and consider whether your local commits have already been shared.
Best Value
When integrating remote commits will not fix the rejection
Git distinguishes a client-side rejected update from a remote rejected update. The latter means the server refused the push and may indicate a hook, permission issue, or repository setting. The git-push documentation describes server-side policies including receive.denyNonFastForwards, receive.denyCurrentBranch, and deletion policies.
- If the status says “remote rejected”: read the accompanying reason. Address the named policy or ask the repository administrator; a merge may not resolve a hook or permission restriction.
- If it is a non-fast-forward rejection: fetch and integrate the correct remote branch, then retry the push.
- If the message is unclear: keep the full terminal output and confirm the remote and branch before changing history or settings.
Why force-pushing is not the routine fix
The git-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 and is safer than plain force in some cases, but it is not the ordinary solution when the goal is to keep both sides’ work. The manual also warns that the shorthand can interact badly with background fetches that update remote-tracking references. For a normal non-fast-forward rejection, integrate the remote commits instead.
Quick Recap
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.
