Skip to main content
This page is for whoever is responsible for reviewing a migration PR and merging its changes into the dev database. It assumes the PR has already passed normal code review — this is the DB-specific check before merge.

​
Workflow

1

Check out the PR branch and pull latest main

Pulling main into the branch first (rather than testing it in isolation) surfaces any schema conflicts with migrations merged after the branch was created — better to catch drift here than after merge.
2

Regenerate the Prisma client locally

3

Run a full local bootstrap against the merged branch

Watch the output closely for warnings or errors — not just a failed exit code. Prisma often prints non-fatal warnings (e.g. about implicit data loss on a column change) that won’t stop the migration but should stop you. See Data Migration for handling this safely.
4

Resolve any warnings/errors/ data migration

If something’s wrong — fix it on the branch (or kick it back to the developer) before proceeding. Don’t merge a migration with an unresolved warning just because it “ran.”
5

If everything passes: force-add the migration file and merge

The migration file generated in step 3 (under prisma/migrations/) is not tracked by git by default — this repo has prisma/migrations under .gitignore. Before merging, explicitly force-add it:
Confirm it shows up in git status/the diff before pushing — a missed -f here means the migration file silently never reaches main, and db:bootstrap:dev will run against a schema that doesn’t match what was actually reviewed.Once confirmed committed, merge the branch into main.
6

Apply the migration to the dev database

This runs prisma migrate deploy against .env.dev (applying only pending migration files, unlike migrate dev which also generates new ones) followed by the dev seed script.
Repeat this exact process for every branch/PR that touches the schema — each one gets its own local bootstrap-and-verify pass before merge, even if it looks like a small change.