Q: You merged a PR into `main` that turned out to be broken in production. The merge has been there for two hours and 15 commits have landed since. How do you back it out safely?
You can't reset main — it's shared and 15 other commits have built on top. The right tool is git revert, which creates a new commit that ...
🛠️ Production Runbook & Step-by-Step Resolution
Production Solution & Architecture
You can't reset main — it's shared and 15 other commits have built on top. The right tool is git revert, which creates a *new* commit that undoes the changes. For a merge commit you need -m to tell Git which parent to revert to (the "mainline"): -m 1 means "treat parent 1 (the main side) as the mainline, and revert everything that came in from the feature side." -m 2 would do the opposite. Push the revert. Now main is back to a working state and the 15 unrelated commits are preserved. Gotcha: if later you want to re-merge the fixed version of that feature branch, a plain merge will appear to do nothing because Git thinks those changes are already on main (they were, then reverted). You either revert the revert (git revert ) before re-merging, or rebase the feature branch onto current main so the commits get fresh hashes.
git revert -m 1 <merge-commit-sha>
- Immediate Triage: You can't reset main — it's shared and 15 other commits have built on top. The right tool is gi
- Run targeted verification commands before modifying configuration.
- Automate permanent guardrails (CI check, alerts, IaC policy) to prevent recurrence.