The commit history was clean until you pulled the trigger. One git reset --hard and the codebase shifted into an unknown state. This is Git reset chaos testing—forcing the repository into unpredictable conditions to see if your workflows, automation, and people can take the hit and recover fast.
Git reset chaos testing is about more than undoing commits. It’s about introducing deliberate disruption in a controlled environment. You roll back branches, rewrite history, change HEAD pointers, and break assumptions in CI/CD pipelines. The goal is to reveal weak spots in tooling and process before real-world incidents hit production.
Start with a stable repo. Mirror it into a sandbox. Use commands like:
git reset --hard HEAD~3
git reset --mixed ORIG_HEAD
git reset --soft <commit>
Combine these with chaotic merges and forced pushes to simulate worst-case scenarios. Observe how systems respond—the build server, deployment scripts, code review tools. Measure recovery time. Track which dependencies fail silently and which fail loudly.