I ran git reset and Terraform screamed.
It wasn’t code that broke — it was the state. Terraform thought the world was one way, my repo said another, and now we were in the dangerous middle. If you’ve ever mixed Git history rewrites with Terraform state, you know how subtle and destructive this drift can be. The wrong reset can take hours — or days — to untangle.
Git reset changes the commit tree. Terraform works by tracking state, often stored remotely. If you roll your Git history back without rolling the state data back, Terraform sees a ghost version of reality. Resources may try to re-create themselves. Destroyed infrastructure can be planned for “creation.” Whole environments can shift because Terraform is blind to your Git history — it only trusts the state.
To reset safely, you need both worlds in sync:
- Check the last applied state with
terraform state list before any Git operation. - If you must
git reset --hard, match it with a state rollback. Use terraform state pull to back it up, and restore as needed with terraform state push. - Coordinate with remote backends like S3, GCS, or Terraform Cloud. These keep the true state history, but they won’t roll back on their own.
- Run
terraform plan before and after the reset to watch for unexpected changes. If you see massive diffs, the sync is broken.
Never assume the infra will follow your commits. Git and Terraform are separate timelines. The safest approach is to treat every Git history rewrite like surgery on a live system: deliberate, tracked, and recoverable.
The quickest way to avoid this mess? Reduce the time between change, plan, and apply. Use automation to test and preview Terraform changes without touching real infra until verified. That’s where hoop.dev comes in — spin it up, connect your repo, and see Terraform changes live in minutes. No state drift. No blind resets. Just clean, instant feedback before you commit.
Try it now and stop fearing git reset with Terraform.