You can always revert (i.e. undo in a new commit) the faulty commit. That will keep the history. This meme is not just about pushing straight to master, it’s about push --force which overwrites the remote branch completely, changing history.
Sometimes there’s only the nuclear option left, I have only done it a few times, someone merged a major refactoring and we ended up reverting by changing history.
I have also observed that when you revert with git revert and then merge back some time later git can get confused about if a commit was merged or not.
Mind you we didn’t use git flow or other smart processes to our own regret.
git can get confused about if a commit was merged or not.
You have to revert the revert before re-merging the branch. Otherwise git keeps track of the commits that you reverted and doesn’t apply them ever again.
I mean, it should be a protected branch to prevent against that.
Sometimes there’s no other option when someone merged develop into master just before a critical bug was found.
You can always revert (i.e. undo in a new commit) the faulty commit. That will keep the history. This meme is not just about pushing straight to master, it’s about
push --forcewhich overwrites the remote branch completely, changing history.Sometimes there’s only the nuclear option left, I have only done it a few times, someone merged a major refactoring and we ended up reverting by changing history.
I have also observed that when you revert with
git revertand then merge back some time later git can get confused about if a commit was merged or not.Mind you we didn’t use git flow or other smart processes to our own regret.
You have to revert the revert before re-merging the branch. Otherwise git keeps track of the commits that you reverted and doesn’t apply them ever again.
See: https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt
Thanks for the info, I think that’s exactly what we didn’t do.