Why aren't reverts more widely used? It seems a lot of devs I've worked with don't understand them, and to me they seem so simple and are so much safer than destroying/rewriting history.
1. Developer writes some code in a branch.
2. Developer merges code into master before the code was actually ready to be deployed.
3. Developer reverts the merge commit in master to roll back everything.
4. Developer fixes the code in their branch.
5. Developer merges their code into master.
6. Their code doesn't show up in master, since it was already merged in and the revert is part of the official history of the branch in master.
7. Developer has to make a revert of the revert and then untangle the mess.
In your scenario, it's a puzzle to unfuck, but it's unfuckable after a bit of work. In the alternative you run the risk of losing work, or blowing out other's commits and causing work for multiple other team members.
I guess my point was that I feel "revert commits" should be treated as the default, and the goto in most situations, and only using something like `git reset HEAD^ --hard` when you really need to, or a revert won't do. I'll be honest, I sometimes use a "reset and force push" when I've fucked up an ugly merge, or I want to undo the last few commits at once, but it's the exception, not the first tool I reach for.
Not only does it preserve the change in an easy-to-see manner, but you can also provide more context on why you undid your commit (my revert messages often read like "Revert "previous commit message here" due to it potentially causing some older android devices to break. More info at ticket #1234")
Now not only do you have a clear history of what happened (someone added X, then you undid X at a later date), but you also have context for why the change was undone, and can either revert the revert if you need to, or just re-do the work in a new commit later.
It's a great "oh shit" button that I'm much more willing to use since I know I won't have to worry about "rescuing" the commit later. If something goes wrong and I have a hunch it was caused in a commit, i'll often just revert it and investigate later when I have time.
See "All the things your branch has ever been" http://h2.jaguarpaw.co.uk/posts/git-survival-guide/
a revert keeps that history forever in your repo (unless you do something to explicitly delete it), which IMO is just as important as all other commits.