Reputation: 13813
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
Upvotes: 3
Views: 397
Reputation: 1134
This workflow explains everything you need to know. It's a great resource IMHO.
Credits: Justin Hileman
Upvotes: 5
Reputation: 11910
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.
Upvotes: 1
Reputation:
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.
Upvotes: 2