3 ms·

I will explain a common problem with revert commits: 1. Developer writes some code in a branch. 2. Developer merges code into master before the code was actua

• Klathmon 8y ago
  I can understand that, but I still would prefer that over the alternative of changing history, losing context at why the revert happened (or that it happened at all!), and having to dig through reflog and hope that the machine that it was done on is available and hasn't dumped the code to be able to recover the commit needed. 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.