All migration files are committed to version control

Migration files in .gitignore mean the team's schema history exists only on individual developers' machines and the production database. When a new developer clones the repo, they cannot reproduce the database schema. When the production database is lost, the schema cannot be reconstructed. ISO 25010 recoverability requires that schema history is independently reproducible; migration files in version control are the mechanism. Prisma's migration_lock.toml is especially critical — if gitignored, team members may apply migrations in inconsistent order and produce divergent schemas.

Remove migration directories from .gitignore and commit all migration files. Verify migration_lock.toml (Prisma) is tracked. Add migration execution to your deployment pipeline.

# Remove migration exclusion from .gitignore
# Edit .gitignore — delete lines like:
# prisma/migrations/
# supabase/migrations/

# Stage and commit existing files
git add prisma/migrations/
git add prisma/migrations/migration_lock.toml
git commit -m "chore: track migration history in version control"

# .github/workflows/deploy.yml
- name: Apply pending migrations
  run: npx prisma migrate deploy
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}

If migration files were previously in .gitignore and are now untracked, audit whether any were applied to production but not committed — npx prisma migrate status will surface applied-but-missing migrations.