Git rebase is the scalpel for your commit history. It slices away noise, rearranges code evolution, and leaves a history you can trust. But when the code you’re rebasing touches a live database, the operation turns delicate. One wrong move and your clean branch leaves behind corruption, mismatched records, or broken migrations.
Database access during Git rebase demands precision. Every migration, seed, and schema change needs to align perfectly with the commit you land on. If a migration runs twice, tables might duplicate. If a migration gets skipped, schema drift spreads silently. And when multiple developers branch off and run their own migrations, rebasing without a plan can break the environment for everyone.
The solution starts with discipline. Map every migration to a specific commit. Version control your database schema alongside the code, not separately. Never run migrations ad‑hoc during a rebase—commit them, track them, and replay them in the exact sequence matched to your branch history. Use feature flags to shield incomplete changes so rebasing doesn’t accidentally expose unfinished database logic to production.