Branch merge workflow for sequential migrations - lessons learned #5581
EliasBorrajo
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Team workflow with sequential migrations - how we handle merges
Sharing a workflow that works well for us in case it helps others.
The core idea: each branch owns its own
drizzle/state, and the parent branch is always the source of truth. You don't avoid mergingdrizzle/— you just follow a strict protocol when you do.The problem
With sequential numbering, two developers working in parallel can both generate a
0007_snapshot.jsonwith different content. The.sqlfilenames are unique, but the snapshot is what Drizzle uses to know the current schema state — two conflicting snapshots at the same number means Drizzle can no longer reliably generate the next migration.The solution: always regenerate on top of the parent
When finishing a feature branch, don't push your
drizzle/as-is. Instead:Step 1 — Pull the parent branch and resolve schema conflicts
git pull origin dev # resolve conflicts in schema.tsStep 2 — Discard your drizzle/, restore the parent's
The parent's
drizzle/is the baseline. Your locally generated migrations are thrown away.Step 3 — Regenerate cleanly on top of the parent
pnpm db:generate pnpm db:migrate # verify locally git add drizzle/This produces a single clean migration on top of the parent's history — no snapshot conflicts, no stale state.
Why not timestamps?
Timestamps solve the numbering collision problem, but they're not Drizzle's default. We preferred keeping the standard and solving the problem at the workflow level instead.
Beyond that, timestamps don't fully eliminate the manual work. You still need to merge
_journal.jsonby hand and make sure the entry order and indices are consistent — which can get messy when several branches are in flight at the same time.Why not
pusheverywhere?pushis great for solo dev, but it can silently drop columns on rename — not acceptable in prod.migratekeeps full control over what runs on the database.Happy to answer questions, if anything is unclear.
I hope it helps some people out there who had the same issue !
Would love to know if others have a different approach
Beta Was this translation helpful? Give feedback.
All reactions