reverting push'd git commit

I've got a repo with two branches-- master and dev. I was working on the master branch and pulled, and got a message that the repo was up to date. I 开发者_Python百科committed my changes, and pushed to the remote repo (on github). I got a message saying that some changes were rejected.

I then did a git pull origin dev, which apparently was the wrong thing to do-- since it merged the dev branch with my master, and like an idiot I didn't notice this until I'd already pushed again. So the last commit shows Merge branch 'dev' of github.com:myuser/myrepo.

I can get back to the last known good status on my local repo by doing a git reset --hard [sha], with [sha] being the commit before the merge (though I'm not sure how to then make that change to the origin)-- or from what I've read I can also do a git revert -m and then commit/push that change.

Can anyone walk me through the "right way" to undo my merge, and restore both branches back to where they were prior to the merge?

Thanks-- if it matters this is a shared repo with only two developers, so it's not under heavy changes.

Edit to add: please talk to me as if I were a child. I have to admit this Git stuff still confuses me, so I'm far from a power user! Thanks

The git reset --hard [sha] will correct the branch on your local repository. To force this push to work, you can do a git push origin +master:master. The + sign will force the non-linear push to work.

If the other developers have already pulled you wrong commit, they will have to do a git remote update, then a git reset --hard origin/master (provided that they are on their master branch, and have not made any other commits.

Please use these commands with some caution :-). Good luck.

FelipeFG's answer works fine in a two-developer context where you can easily coordinate redoing the other guy's local repository, but you're actually better off using git revert -m<parent id of mainline branch, 1 in this case> <commit ref>. Then, when you're finished fixing it, just git revert <revert commit>, and git merge dev (it's important to revert your revert for this case, because otherwise git merge dev will not consider your old merge an ancestor, and this will lead to conflicts that have to be resolved).

The history will be ugly, but it will also support fast-forwarding, and you won't have to worry about some poor sap untangling a mess of local conflicts thanks to your history revision.

See http://opensource.apple.com/source/Git/Git-26/src/git-htmldocs/howto/revert-a-faulty-merge.txt for details.