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 --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.
What happens when you want to merge again? Won’t it say already up to date or something cause the commits are already there?
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-lease
Didn’t you guys hear that GitHub has solved slavery? It’s no longer master branch, it’s main.
I love how they’re smiling
