Introduction

Replacing a local branch with the remote version is a common cleanup step after a bad rebase, local experiments, or accidental divergence. The operation is simple, but it is destructive for local commits and local working-tree changes, so the safe approach is to verify the branch, optionally create a backup, and then reset intentionally.

Confirm What You Want to Replace

Before using reset --hard, confirm the situation:

1. the local branch really should match the remote exactly
2. any unpushed local commits are disposable or already backed up
3. uncommitted work has been stashed or otherwise preserved

If there is any doubt, create a backup branch first.

git switch my-branch
git branch backup/my-branch-before-reset

That one command gives you a quick escape hatch if you realize afterward that local work mattered after all.

Standard Replacement Workflow

The normal sequence is to fetch the remote state, switch to the branch, and reset the branch tip to the remote-tracking branch.

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

After this:

1. the branch pointer matches origin/my-branch
2. the index matches that commit
3. tracked files in the working tree match that commit too

This is the standard way to say “make my local branch exactly what the remote currently is.”

Clean Untracked Files Only If You Need a Truly Pristine Tree

git reset --hard does not remove untracked files. If you want your checkout to look like a brand-new clone of that branch, clean those files explicitly.

git clean -fd

Be careful with -x, which also removes ignored files. That may delete local caches, environment files, or other machine-specific artifacts you did not intend to destroy.

Protect Yourself With a Quick Inspection Step

If you want a slightly safer workflow, inspect the difference before the reset.

1git fetch origin
2git switch my-branch
3git log --oneline --left-right HEAD...origin/my-branch
4git diff --stat HEAD...origin/my-branch

This gives you a final chance to notice that the branch contains useful local work before you throw it away.

Recover Mistakes With reflog

If you reset the wrong branch or regret the replacement immediately afterward, reflog usually still knows where the branch pointed before the reset.

git reflog
git switch my-branch
git reset --hard PREVIOUS_SHA

That is why quick recovery is possible after many “oops, wrong hard reset” mistakes. The old tip usually is not gone instantly.

Understand the Difference Between Local Reset and Remote Rewrite

Replacing your local branch with the remote branch changes only your clone. It does not modify the remote repository. That is an important distinction.

If the remote branch itself is wrong and needs rewriting, that is a separate operation and usually involves coordination plus a push such as --force-with-lease. Do not blur those two workflows together.

Use This Pattern in CI and Disposable Workspaces

The same idea is common in automation. CI jobs often want a deterministic working copy with no leftover local history or untracked files from previous runs.

1git fetch --prune origin
2git switch main
3git reset --hard origin/main
4git clean -fd

That is a good pattern for disposable workspaces because it removes drift and keeps builds repeatable.

Common Pitfalls

The biggest mistake is running the hard reset without a backup when local commits might still matter. Another is assuming reset --hard removes untracked files, which it does not. Developers also confuse “replace my local branch” with “rewrite the remote branch,” which are very different operations with very different risk.

Summary

• Use git fetch plus git reset --hard origin/branch to replace a local branch with the remote version.
• Create a backup branch first whenever there is uncertainty about local commits.
• Use git clean -fd only when you also need untracked files removed.
• Recover accidental resets quickly with git reflog.
• Keep local branch replacement separate from any remote history-rewrite workflow.