Git Reset to Remote: How to Sync Your Local Branch

To reset your local Git branch to match a remote branch, use git reset --hard origin/<branch>. This command discards all local commits and uncommitted changes, making your local branch identical to the remote one. It’s a powerful but destructive operation, so it’s essential to understand exactly what it does before running it.

What Does “Reset to Remote” Actually Mean?

When you work with Git, your local repository and the remote repository (like GitHub, GitLab, or Bitbucket) can drift apart. Your local branch may have commits that exist only on your machine, or the remote may have commits you haven’t pulled yet. “Resetting to remote” means forcibly moving your local branch pointer to match the remote branch’s commit, discarding any local changes that aren’t on the remote.

This is different from a simple git pull, which merges or rebases your local changes with the remote ones. A reset doesn’t merge anything—it simply overwrites your local state. Think of it as saying, “Forget everything I’ve done locally; I want exactly what’s on the server.”

Why You Might Need to Reset

There are several common scenarios where resetting to remote is the right move:

You made a mess locally: You’ve committed broken code, or your working directory is full of experimental changes you no longer want.
You accidentally committed to the wrong branch: You meant to work on feature/login but committed to main.
Your local branch is out of sync after a force-push: A teammate force-pushed to the remote, and your local history no longer matches.
You want to discard all uncommitted changes: You’ve edited files but want to revert to the last committed state from the remote.

In each case, resetting gives you a clean slate aligned with the remote. However, it’s rarely the only option—sometimes a safer command like git pull --rebase or git stash is more appropriate.

How to Reset: Step-by-Step

Here’s the exact process to reset your local branch to the remote state:

Fetch the latest from the remote: Run git fetch origin. This updates your remote-tracking branches (like origin/main) without touching your local branches.
Check which branch you’re on: Use git branch --show-current to confirm you’re on the branch you want to reset.
Reset your local branch: Run git reset --hard origin/<branch-name>. Replace <branch-name> with the actual branch name, e.g., git reset --hard origin/main.
Verify the result: Run git status to see that your working tree is clean and git log --oneline -5 to confirm your local history matches the remote.

If you also want to remove untracked files (files not tracked by Git), you can run git clean -fd after the reset. Be careful—this deletes files permanently.

What Exactly Gets Discarded?

Understanding what git reset --hard does is crucial. It affects three areas:

Your working directory: All uncommitted changes to tracked files are reverted to the state of the commit you reset to.
Your staging area (index): Any files you had staged are unstaged and reverted.
Your branch pointer: The branch itself moves to the specified commit, discarding any commits that aren’t ancestors of that commit.

Untracked files (new files you created but never added) are not touched by git reset --hard. They remain in your working directory. To remove those, you need git clean as mentioned above.

Common Mistakes and How to Avoid Them

Even experienced developers make errors when resetting. Here are the most common pitfalls:

Resetting without fetching: If you run git reset --hard origin/main without fetching first, you’re resetting to the last known state of the remote, which might be outdated. Always fetch first.
Using the wrong branch name: Typing origin/mian instead of origin/main will fail, but Git will give an error. More dangerous is resetting to the wrong local branch—double-check you’re on the right branch.
Forgetting about local commits: If you have local commits you want to keep, resetting will delete them. If you think you might need them later, create a backup branch first: git branch backup-branch.
Using --hard when you meant --soft or --mixed: --soft keeps your changes staged, --mixed keeps them unstaged. Only --hard discards everything.

Alternatives to a Hard Reset

Resetting is not always the best tool. Consider these alternatives depending on your situation:

git pull --rebase: If you have local commits that you want to keep, but the remote has moved ahead, rebasing replays your commits on top of the remote’s latest. This is safer than resetting because it doesn’t discard anything.
git stash: If you have uncommitted changes you want to temporarily set aside, git stash saves them and cleans your working directory. You can later apply them with git stash pop.
git revert: If you’ve already pushed bad commits to the remote and want to undo them without rewriting history, use git revert to create a new commit that undoes the bad ones.
git checkout: If you only want to discard changes in a single file, use git checkout -- <file> instead of resetting the whole branch.

When to Avoid Resetting

There are situations where resetting is dangerous and should be avoided:

You have unpushed commits that others might have based work on: If you’ve shared your branch with teammates, resetting and force-pushing can cause chaos. Prefer git revert in this case.
You’re on a shared branch like main: Resetting main and force-pushing can break the repository for everyone. Only do this if you’re absolutely sure and have communicated with your team.
You haven’t committed your work in a while: If you have hours of uncommitted work, resetting will destroy it. Consider committing or stashing first.

Frequently Asked Questions

Will `git reset --hard` delete my untracked files?

No. git reset --hard only affects tracked files and the staging area. Untracked files (files never added with git add) remain untouched. To delete those, you need to run git clean -fd separately.

Can I undo a hard reset?

If you haven’t run git gc (garbage collection), you might be able to recover lost commits using git reflog. Run git reflog to see a history of your branch movements, find the commit you want, and reset back to it. However, if you’ve also run git clean, untracked files are gone for good.

What’s the difference between `git reset --hard origin/main` and `git pull origin main`?

git pull fetches the remote and then merges (or rebases) the remote changes into your local branch. It preserves your local commits. git reset --hard discards all local commits and changes, making your branch exactly match the remote. Use pull when you want to keep your work; use reset when you want to abandon it.

Why do I get “fatal: ambiguous argument ‘origin/main'”?

This error means Git can’t find a remote-tracking branch named origin/main. It usually happens because you haven’t fetched from the remote yet. Run git fetch origin first, then try again. Alternatively, check the exact branch name with git branch -r.

Should I use `--hard` or `--soft`?

Use --hard when you want to completely discard all local changes and commits. Use --soft if you want to move the branch pointer to the remote commit but keep all your changes staged in the index. Use --mixed (the default) if you want to keep changes unstaged. For most “reset to remote” scenarios, --hard is what you want.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →