The code was wrong, and the clock was ticking. You needed a clean history, not a messy trail of failed commits. That’s when git reset becomes the fastest way to regain control.
git reset changes the current HEAD to the specified state. It can rewrite history, discard changes, and align your branch with a known good commit. For Site Reliability Engineering (SRE) work, where uptime is sacred and rollback speed defines success, understanding git reset is not optional — it’s survival.
There are three modes:
1. git reset --soft <commit>
Moves HEAD to <commit>. Keeps your changes staged. No files are touched. Good for regrouping commits before a push.
2. git reset --mixed <commit> (default)
Moves HEAD, unstages changes, but keeps them in your working directory. Useful for retargeting work without losing edits.
3. git reset --hard <commit>
Resets HEAD and wipes out all changes — staged and unstaged. This is destructive. Use with caution when you must revert immediately and start fresh.
For an SRE mid-incident, the common pattern is:
git fetch origin
git reset --hard origin/main
This syncs your branch with the source, erasing local drift. Faster than cherry-picking fixes. Cleaner than merge conflicts during an outage.
To avoid disasters:
- Verify commit hashes with
git log - Never
--hard without being sure - Coordinate resets in shared repos to prevent overwriting teammates’ work
In production environments, git reset is a scalpel. Use it to cut out broken code before it bleeds into the systems you protect. Document every reset. Treat each as a state change in your incident timeline.
Speed matters. Clarity matters more. Master git reset so your repo can move as fast as your recovery plan.
Want to see this workflow in action? Launch it instantly with hoop.dev and watch it go live in minutes.