Introduction

After someone force-pushes a branch, a normal git pull is usually the wrong first move because the remote history has been rewritten. The safer workflow is to fetch first, inspect how your local branch differs from the new remote branch, and then choose whether to discard local history or replay it.

What a Forced Push Actually Changes

A forced push replaces the remote branch tip with a different commit chain. Your local branch may still point to commits that no longer exist on the remote branch, which is why a blind pull can produce confusing merges or refusal messages.

Start by updating your remote-tracking refs without touching your current branch:

git fetch origin

Then inspect the difference:

git switch my-branch
git log --oneline --graph --decorate HEAD..origin/my-branch
git log --oneline --graph --decorate origin/my-branch..HEAD

Those two comparisons show what arrived from the remote and what exists only in your local branch.

Case 1: You Want to Match the Remote Exactly

If your local commits are disposable or already backed up elsewhere, reset the branch to the rewritten remote state.

git switch my-branch
git fetch origin
git reset --hard origin/my-branch

After that, your local branch exactly matches the new remote history.

This is the cleanest path when you were only tracking the branch and had no local work that needs to survive.

Case 2: You Need to Keep Local Commits

If you have local commits that still matter, do not reset immediately. Make a backup branch first, then replay your work onto the new remote history.

1git switch my-branch
2git branch backup/my-branch
3git fetch origin
4git rebase origin/my-branch

If the rebase becomes messy because the remote branch changed heavily, create a fresh branch from the remote and cherry-pick only the commits you still want:

git switch -c repaired-branch origin/my-branch
git cherry-pick <commit-id>

This is often easier when you only have a small number of local commits.

Handle Uncommitted Changes First

Do not reset or rebase over a dirty working tree. Either commit your pending work or stash it first.

git stash push -u -m "save work before force-push recovery"

That keeps recovery steps focused on branch history rather than mixing them with unrelated working-tree edits.

Why git pull Hides the Real Decision

git pull is a convenience command that combines fetch plus merge or rebase. After a forced push, the real question is not "how do I pull" but "do I want the new remote history, my local commits, or both."

Separating git fetch from the recovery step makes that decision explicit. It also reduces the chance of creating an accidental merge commit on top of rewritten history.

Keep a Recovery Path

Even when you think your local commits do not matter, creating a backup branch is cheap insurance:

git branch backup/pre-reset

If you later realize something important disappeared, the backup branch or the reflog gives you a path back.

Common Pitfalls

Running git pull immediately after a forced push hides the most important question, which is whether local history should be discarded or preserved.

Using git reset --hard without first backing up local commits can permanently remove work you still needed.

Starting a rebase while uncommitted changes are present makes recovery harder than it needs to be.

Assuming a forced push simply added commits is wrong. It replaced part of the branch history.

Ignoring git reflog after a bad recovery step wastes one of Git's best safety nets.

Summary

• After a forced push, start with git fetch origin, not a blind git pull.
• Compare local and remote history before choosing a recovery action.
• Use git reset --hard only when you want to match the remote exactly.
• If local commits matter, back them up and rebase or cherry-pick them onto the new remote history.
• Keep a backup branch or reflog-based recovery path before doing destructive steps.