Need to reset git branch to origin version


I was accidentally working on a branch I shouldn’t have been for a while, so I branched off of it giving it the appropriate name. Now I want to overwrite the branch I shouldn’t have been on to the version from origin (github). Is there an easy way to do this? I tried deleting the branch and then resetting up the tracking branch, but it just gives me the version I was working on again.



If you haven’t pushed to origin yet, you can reset your branch to the upstream branch with:

git checkout mybranch
git reset --hard origin/mybranch

(Make sure that you reference your latest commit in a separate branch, like you mention in your question)

Note that just after the reset, [email protected]{1} refers to the old commit, before reset.

But if you had already pushed, see “Create git branch, and revert original to upstream state” for other options.

With Git 2.23 (August 2019), that would be one command: git switch.
Namely: git switch -C mybranch origin/mybranch


C:\Users\vonc\git\git>git switch -C master origin/master
Reset branch 'master'
Branch 'master' set up to track remote branch 'master' from 'origin'.
Your branch is up to date with 'origin/master'.

That restores the index and working tree, like a git reset --hard would.

As commented by Brad Herman, a reset --hard would remove any new file or reset modified file to HEAD.

Actually, to be sure you start from a “clean slate”, a git clean -f -d after the reset would ensure a working tree exactly identical to the branch you just reset to.

This blog post suggests those aliases (for master branch only, but you can adapt/extend those):

   resetorigin = !git fetch origin && git reset --hard origin/master && git clean -f -d
   resetupstream = !git fetch upstream && git reset --hard upstream/master && git clean -f -d

Then you can type:

git resetupstream


git resetorigin


  • 32

    this will DELETE UNSTAGED/STAGED changes (from the –hard)

    Aug 30, 2012 at 22:02

  • 7

    I have used the git reset --hard origin/mybranch command several times when I didn’t care about any local changes and just wanted a clean copy that matched the origin. However, today, this didn’t work — I still had a handful of new, unstaged files, and git kept promising me that it was at HEAD. The note about git clean -f -d fixed that by wiping up all the new files that I didn’t want.

    Oct 31, 2016 at 21:21

  • @MatthewClark That is expected: see comment on

    – VonC

    Oct 31, 2016 at 21:35

  • 2

    Great! Also many times i have used git reset --hard HEAD to revert to a previous commit, ignoring any changes

    Dec 23, 2016 at 16:03

  • Is this possible with sourctree, too?

    – Lonzak

    Jun 13, 2017 at 8:14


There is a slightly easier way to do this:

git reset --hard @{u}

@{u} is a shortcut for whatever your tracking branch is, so if you’re on master and that tracks origin/master, @{u} points to origin/master.

The advantage of using this is that you don’t have to remember (or type out) the full name of your tracking branch. You can also make an alias:

git-reset-origin="git reset --hard @{u}"

which will work regardless of the branch you’re currently on.


  • 5

    Note, in powershell you need to escape {u} so the full command will be something like git reset --hard "@{u}"

    – sommmen

    Dec 15, 2020 at 10:19

  • 2

    Thanks for this! Now that I learned it exists, I found it is documented in

    Aug 27, 2021 at 16:28


Assuming this is what happened:

# on branch master
vi                 # you edit file
git add            # stage file
git commit -m "Fix the bug" # commit
vi                 # edit another file but do not commit yet

Then you realise you make changes on the wrong branch.

git checkout -b mybranch    # you create the correct branch and switch to it

But master still points to your commit. You want it to point where it pointed before.


The easiest way is:

git branch --force master origin/master

Another way is:

git checkout master
git reset --soft origin/master
git checkout mybranch

Note that using reset --hard will cause your uncommitted changes to be lost ( in my example).