Is this a good strategy to undo git stuff?

Question

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

Answer 1

This workflow explains everything you need to know. It's a great resource IMHO.

Credits: Justin Hileman

Answer 2

Yes -- git revert is absolutely the appropriate approach in this situation, as it preserves the history of the bad commit having been made, then later removed.

Answer 3

Normally for "work in progress", I will make a sequence of commits, then do a git rebase -i base to clean up my history - consider that the reader (possibly yourself) will find this easier to see later on in the future.

Once I then push it, I will consider that history immutable, and will then prefer the git revert approach.