I lost an entire afternoon to a single git reset.
It looked harmless. One command. A quick cleanup before pushing the code. But seconds later, commits were gone, the working directory was half-wrecked, and my stomach had dropped. The pain point hit hard: git reset doesn’t ask for permission—it rewrites history, and it will take anything in its way.
The trouble isn’t knowing what git reset does. It’s the context. Hard, mixed, and soft resets each flip different switches in Git’s internal state. If you pick the wrong one under pressure, you can blow away hours—or days—of work. Even seasoned teams have made the same mistake: assuming ‘undo’ in Git works the same way as in a text editor. It doesn’t.
Git reset pain points show up the most during time-sensitive fixes, messy merges, or when cleaning large feature branches. A hard reset can ditch local changes without a trace. A mixed reset can leave your staging area in chaos. A soft reset can stack uncommitted work so high that you lose the ability to separate it cleanly. The risk multiplies when multiple developers touch the same branch and expect its history to be reliable.