I rebased at 2 a.m. and my SQLPlus session froze mid-execution.
You know the moment: your Git branch is dangling between commits, your SQLPlus script is half-fed to the database, and you’re holding your breath hoping nothing burns. This is where Git rebase and SQLPlus misunderstand each other, and where most teams lose hours untangling knots that should never have formed.
Why Git Rebase and SQLPlus Collide
Git rebase rewrites commit history. That’s great for clean timelines, but dangerous when your local changes include schema migrations, PL/SQL packages, or data seeds executed with SQLPlus. SQLPlus, by design, doesn’t care about Git state. It runs whatever you throw at it, so if you replay commits, you risk re-running scripts in ways the database never forgets.
The Safe Flow
Start with a staging branch. Before you rebase, verify no SQLPlus scripts in your changes have side effects that can’t be repeated without harm. Use versioned migration files where each script is idempotent. When rebasing against main, resolve code conflicts first, then run database migrations in isolation after the rebase completes, not during. This keeps Git history clean and database state stable.