Database migrations in teams: avoiding conflicts
Team of 5 developers, all writing migrations. We hit migration conflicts regularly: two developers create a migration on the same day with the same timestamp prefix.
What conventions or tooling help here?
Use millisecond timestamps in migration filenames (date(“Y_m_d_His”)) instead of the default which only goes to seconds. Reduces collision probability significantly in active teams.
Convention: never reorder migration timestamps after they are committed. If two migrations conflict, the fix is to add a new migration that combines the intent, not to renumber.
In CI, run php artisan migrate --force on a clean DB and then php artisan migrate:status. If any migrations are out of sequence or unapplied after a full run, fail the build.
The squash command (migrate:squash) in Laravel 8+ collapses all migrations into a single schema.php file. Useful when the migration history is long and slowing down CI. Do it at major release milestones.
We put migration authorship in the class docblock. Not enforced but useful for blame when a migration breaks something: you know who to ask.
Feature branches can each contain migrations. If two branches both add a column to the same table, merging creates a duplicate column problem. Our rule: migrations in feature branches are squashed into one before merge.
```php blocks are runnable.