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.

• ID: database-design-operations.migration-versioning.migrations-in-vcs

• Severity: medium

• What to look for: Read the .gitignore file and check whether any migration directories are listed. Common patterns to check: migrations/, prisma/migrations/, drizzle/, supabase/migrations/, db/migrations/. Also check whether ORM lock files are excluded — Prisma's prisma/migrations/migration_lock.toml must be committed (it tracks which migrations have been applied). If the project uses git, check that migration files appear tracked (not in .gitignore). List all restore-related documentation and look for evidence that migrations are deployed alongside code changes (CI/CD pipeline that runs migrations on deploy, deployment documentation that mentions migrations).

• Pass criteria: Migration files are tracked in version control — fewer than 1 migration directory listed in .gitignore. No migration directory is in .gitignore. Lock files (Prisma migration_lock.toml) are committed. README or deployment documentation describes how migrations are applied.

• Fail criteria: Migration directories are in .gitignore. Migration files exist locally but are not version-controlled. Lock files are gitignored. No documentation on how migrations are applied in production.

• Skip (N/A) when: No migration tool is in use (covered by migration-tool-present check).

• Detail on fail: Specify what is excluded. Example: "'prisma/migrations/' is listed in .gitignore — migration history is not version controlled." or "'migration_lock.toml' is gitignored — team members may apply migrations in inconsistent order.".

• Remediation: Remove migration directories from .gitignore and commit all migration files:

  # Remove migration exclusion from .gitignore
  # Edit .gitignore and remove lines like:
  # prisma/migrations/
  # migrations/
  # drizzle/
  
  # Commit existing migration files
  git add prisma/migrations/
  git add prisma/migrations/migration_lock.toml
  git commit -m "chore: track migration history in version control"
  

  Add migration execution to your deployment pipeline:

  # .github/workflows/deploy.yml — run migrations before deploying
  - name: Run database migrations
    run: npx prisma migrate deploy
    env:
      DATABASE_URL: ${{ secrets.DATABASE_URL }}