Managing Laravel Migrations: Consolidate by Model or Keep Separate?

As our project has grown, the number of "migrations" has increased significantly due to the various models and incremental modifications/enhancements, resulting in over 50 files.

@naoufal87 And? Many projects have many more migrations files.

My question is: Should these migration files be consolidated by "Model" or kept separate?

Yes, they should be kept separate. They’re version control files for your database schema.

I'm finding it increasingly difficult to manage and understand them.

Why? The entire point of them is that each migration represents an incremental change to your database schema. You don’t randomly rewrite your Git history and consolidate commits by “topic”. The same goes for your migration files.

You should keep a history of your migration files. You should be able to check out any commit from your project, and be able to run php artisan migrate:fresh to build the database schema as it was in that point of time, and be able to run subsequent migrations as you move through your commits, i.e. during a git rebase session. You can’t do that if in one commit, your migrations are suddenly rewritten.

There is a schema:dump command that you can use to squash the migrations into a single SQL dump. That can be useful if the number of migrations grows into several hundreds, as it can speed up tests.

But 50 migrations should not be an issue of any kind. And you never edit them, you just add new files. Like @martinbean said, they're the version control history of your DB schema.

In PhpStorm you can see current sql structure of the table, including all migrations. Can be more profitable rather check each migration. But as said upper it is normal to have many migrations.