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.
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.
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.
At least always use
git push —force-with-lease. It makes sure you are that the remote hasn’t changed since you lasted pulled. https://git-scm.com/docs/git-push#Documentation/git-push.txt---no-force-with-leaseDidn’t you guys hear that GitHub has solved slavery? It’s no longer
masterbranch, it’smain.I love how they’re smiling
