Until now, if I ever commited and pushed something wrong to the master branch, my way of solving it was, assume the the git log looks like
commit bad_hash
commit another_bad_hash
commit yet_another_bad_hash
commit good_hash
The way I 'solved' the situation in the past was :
git reset --hard good_hash
git push -f origin master
And yes, that will work... but did not seem very elegant, since it effectively remove the commit history.
So after situation which destroyed my ego, I checked out better methods, and came out with the git revert one, essentially I use now
git revert bad_hash another_bad_hash yet_another_bad_hash
git push origin master
The git revert will create three commits (one per reverted hash), after that, a push is needed to update the remote.
Now, question is, is this strategy correct? to me looks much better than the reset --hard, since the history of the repo is not trunkated, and if eventually someone wants to check why there were problems, they can always do a
git diff bad_hash
Is this reasoning correct or am I still missing basic concepts.
Thanks
This workflow explains everything you need to know. It's a great resource IMHO.
Credits: Justin Hileman