When a codebase is locked down, "break glass access"is the emergency key. It’s the controlled bypass that grants a trusted engineer the ability to override normal guardrails. Done right, it’s traceable, secure, and temporary. Done wrong, it’s an open door no one remembers to close.
Break Glass Access Procedures exist for moments when speed beats process. They let you enter without approvals but keep the system protected with audit trails, expiry windows, and minimal privilege scopes. The best procedures demand authentication, capture full logs, and notify stakeholders in real time. Every step should be reversible and documented.
For Git, especially with teams enforcing branch protection and pre-push checks, break glass often means bypassing hooks or resetting history. That’s where Git reset comes in—surgical, precise, but dangerous if mishandled.
Using Git Reset in a Break Glass Scenario
A git reset can fix a bad merge, roll back to a stable commit, or clear out unintended changes. In an emergency flow:
- Authenticate and activate break glass session.
- Identify the exact commit SHA to restore.
- Run
git reset --hard <commit>to instantly revert. - Validate stability with automated and manual tests.
- Push back to the remote with force only if disruption impact outweighs branch safety policies.
- Close the break glass session immediately.
Every command should run inside an isolated, logged context. Avoid casual experimentation. Even a small mistake while in break glass mode can introduce data loss or trigger cascading errors.