Resetting remote to a certain commit – Dev

The best answers to the question “Resetting remote to a certain commit” in the category Dev.


I want to discard all changes done after commit <commit-hash> .
So I did:

git reset --hard <commit-hash>

Now I want to do the same with my remote. How can I do this? I have done some commits (and pushes) after <commit-hash> and I just want to discard them all. Is just something went terribly wrong in the way and I don’t want to make it worse than it is already. ;(

I basically want to rewind my origin/master to <commit-hash>


Using some other answers can result in unnecessary loss of local state. Local changes are not inherently required to change a remote. This method can still wreck your remote if you choose the wrong commit to go back to, but even then you can usually find the right commit and try again.

You must have the desired commit somewhere in your local repo that you want the remote to match.

  1. Do not do any resetting.
  2. Use git log to find the commit you want to the remote to be at. Use git log -p to see changes, or git log --graph --all --oneline --decorate to see a compact tree.
  3. Copy the commit’s hash, tag, or (if it’s the tip) its branch name.
  4. Run a command like:
    git push --force <remote> <commit-ish>:<the remote branch>


    git push --force origin 606fdfaa33af1844c86f4267a136d4666e576cdc:master


    git push --force staging v2.4.0b2:releases

If the forced push fails, it’s likely disabled by the remote. This may be worked around by temporarily changing one or both of receive.denyNonFastForwards and receive.denyDeletes. If your remote is hosted on a service without shell access, it probably has settings you can change to allow forced pushes.

I use a convenient alias (git go) for viewing history as in step 2, which can be added like so:

git config --global alias.go 'log --graph --all --decorate --oneline'


Assuming that your branch is called master both here and remotely, and that your remote is called origin you could do:

 git reset --hard <commit-hash>
 git push -f origin master

However, you should avoid doing this if anyone else is working with your remote repository and has pulled your changes. In that case, it would be better to revert the commits that you don’t want, then push as normal.

Update: you’ve explained below that other people have pulled the changes that you’ve pushed, so it’s better to create a new commit that reverts all of those changes. There’s a nice explanation of your options for doing this in this answer from Jakub NarÄ™bski. Which one is most convenient depends on how many commits you want to revert, and which method makes most sense to you.

Since from your question it’s clear that you have already used git reset --hard to reset your master branch, you may need to start by using git reset --hard ORIG_HEAD to move your branch back to where it was before. (As always with git reset --hard, make sure that git status is clean, that you’re on the right branch and that you’re aware of git reflog as a tool to recover apparently lost commits.) You should also check that ORIG_HEAD points to the right commit, with git show ORIG_HEAD.


If you get a message like “! [remote rejected] a60f7d85 -> master (pre-receive hook declined)

then you have to allow branch history rewriting for the specific branch. In BitBucket for example it said “Rewriting branch history is not allowed”. There is a checkbox named Allow rewriting branch history which you have to check.


On GitLab, you may have to set your branch to unprotected before doing this. You can do this in [repo] > Settings > Repository > Protected Branches. Then the method from Mark’s answer works.

git reset --hard <commit-hash>
git push -f origin master


I solved problem like yours by this commands:

git reset --hard <commit-hash> 
git push -f <remote> <local branch>:<remote branch>