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.
Troubleshooting:
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.
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.
Troubleshooting:
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.
Most other answers – including the accepted one – will result in unnecessary loss of local state.
Local changes are not inherently required to change a remote. You may need to apply local corrections in addition to resetting a remote, but that's a lower priority if your problem is simply that you need to quickly put the remote back to how it was before your push, or you pushed the wrong thing. This method (like any other forced push) has the potential to ruin your remote if you choose the wrong commit, but even then you can usually find the correct one and try again.
You must have the desired commit somewhere in your local repo that the remote should match.
Do not do any local resetting, checking out, or branch switching.
Use
git logto find the commit you want to the remote to be at. Usegit log -pto see changes, orgit log --graph --all --oneline --decorateto see a compact tree.If you cannot find the commit, try checking
git reflogwhich will show the state history of your repo. You may be able to recover the commit from its hash, e.g.:git branch <name for branch of rescued commit> <hash of rescued commit>Copy the commit's hash, tag, or (if it's the tip) its branch name.
Run a command like:
git push --force <remote> <commit-ish>:<the remote branch>e.g.
git push --force origin 606fdfaa33af1844c86f4267a136d4666e576cdc:mainor
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, mnemonic "graph oneline") for viewing history, which can be added like so:
git config --global alias.go 'log --graph --oneline --all --decorate'
Does git revert also affect the remote branch?
[Git] How to 'git reset' a remote branch?
How do I undo a merge commit?
What happens if I encounter conflicts while reverting a commit?
I need to remove the changes associated with a particular commit and then work with the code on my local branch.
If I do a git revert commit_id, will that also automatically affect the remote branch or will it just change my local copy?
Thanks in advance!
Say I have a local branch and I make change A, then push it so both the local and remote has change A. I then realize I don't want change A as there was an error in it. I can use git reset to reset my local branch to the commit before change A, but then if I do that and try to push, it doesn't work. This makes sense because technically the local branch is behind the remote branch. And a solution to this is to just make a "revert change A" commit, but I don't even want my commit history to show these two commits since they cancel each other out
Is there a way to do "git reset" a remote branch?
If nobody has pulled your remote repo yet, you can change your branch HEAD and force push it to said remote repo:
git reset --hard HEAD^
git push -f
(or, if you have direct access to the remote repo, you can change its HEAD reference even though it is a bare repo)
Warning: git reset --hard discards local changes
As dremodaris correctly warns in the comments:
WARNING: the
--hardoption will also make you lose your changes in your local working directory!
Note, as commented by alien-technology in the comments below, on Windows (CMD session), you would need ^^:
git reset --hard HEAD^^
git push -f
And, as noted in the comments by Jon Schneider:
If the command with "
HEAD^" results inerror no matches found: HEAD^, see "git show HEAD^doesn't seem to be working. Is this normal?"
Update since 2011:
Using git push --force-with-lease (that I present here, introduced in 2013 with Git 1.8.5) is safer.
See Schwern's answer for illustration.
What if somebody has already pulled the repo? What would I do then?
Then I would suggest something that doesn't rewrite the history:
git revertlocally your last commit (creating a new commit that reverses what the previous commit did)- push the 'revert' generated by
git revert.
Set the local branch one revision back (HEAD^ means one revision back):
git reset --hard HEAD^
Push the changes to origin:
git push --force
You will have to force pushing because otherwise git would recognize that you're behind origin by one commit and nothing will change.
Doing it with --force tells git to overwrite HEAD in the remote repo without respecting any advances there.