Git reset and SQL*Plus don’t forgive mistakes. Used right, they’re powerful tools for cleaning up bad commits and fixing broken database changes. Used wrong, they erase your progress without warning. Knowing exactly how to reset Git and recover SQL*Plus sessions can save entire sprints.
Understanding Git Reset
git reset changes the state of your repository. It moves the HEAD pointer and rewrites history.
git reset --soft <commit> keeps your changes staged.git reset --mixed <commit> keeps files but unstages them.git reset --hard <commit> discards everything back to the commit you pick.
For rollbacks after a bad check‑in, soft or mixed resets are safer. Hard reset should be deliberate, final, and documented.
The SQL*Plus Angle
SQL*Plus doesn’t have a built‑in undo command. Once a COMMIT runs, changes are permanent. The safest workflow is to test changes inside a controlled transaction.
- Always set
AUTOCOMMIT OFF. - Use
ROLLBACK; to reverse uncommitted changes. - Keep session scripts under version control with Git to align database changes with application code.
When Git and SQL*Plus Collide
Resetting Git can roll back database migration scripts. But your database might already be ahead. If you’ve committed migration files, but already ran them in SQL*Plus, rolling back in Git won’t roll back the database. Sync matters.
- Tag commits when migrations are applied.
- Keep a reversible migration strategy.
- Ensure Git state and database state match before resets.
Recovering Fast
When disaster hits, the only real recovery comes from preparation. Backups and branches protect both code and data. Temporary work should live on feature branches. Database changes should go through repeatable migration scripts instead of ad‑hoc SQL in SQL*Plus.
The Workflow That Works
- Pull latest changes.
- Work on a feature branch.
- Use Git history to test resets safely.
- Run SQL*Plus scripts in a controlled environment.
- Commit and push migration scripts alongside code.
The beauty of git reset and SQL*Plus is control. You can manage risk, fix mistakes, and keep history clean. But that control only works if your process ties code and database changes into one trackable system.
If you want to see a live, production‑ready workflow where Git resets and SQL*Plus changes stay in sync without the usual pain, check out hoop.dev. You can try it in minutes and see how smooth your workflow can be when everything lines up.