Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Just wanted to clarify what the situation would be when migrations are potentially "out of order" due to branching and merging.
I was working on a branch feature_a which I was in a position to commit but not merge and deploy to my staging site. This included a migration 2020_05_10_1200_migration_from_feature_a. I was asked to look at a quick fix for something so I moved back to my staging branch and worked on a quick amend which included another migration 2020_05_10_1230_migration_from_staging. This was pushed up to my server, deployed and all works well. I then went back to feature_a and merged in my staging branch. This resulted in my migrations being kinda out of sync:
/migrations
- 2020_05_10_1200_migration_from_feature_a
- 2020_05_10_1230_migration_from_staging
Since I pushed my last amends to staging the migration 2020_05_10_1230_migration_from_staging has been run but 2020_05_10_1200_migration_from_feature_a has not. If I complete my feature_a and merge that back into staging and deploy, will php artisan migrate see that a migration is missing (i.e. 2020_05_10_1200_migration_from_feature_a) and execute it? Can I (should I?) amend the timestamp of 2020_05_10_1200_migration_from_feature_a to occur after 2020_05_10_1230_migration_from_staging without incident`?
In hindsight, I probably should have git stashed my work on feature a. Lesson learned for next time!
Worth pointing out that I am using Laravel Forge for deployment.
the migrations are handeled in order of the timestamp in the filename (you can change the filenames, if you want, to order the files)
when migrating, Laravel stores which migration was already run, and which still needs to be run (see in your database table migrations) you can also change those values, if you want to run a specific migration again
@Dunsti Thank you. This seems to have worked locally and I have a staging site I can mess around on to double check. I think my fear of amending the migration filenames is because I wasn't 100% sure what the purpose of the migrations table created in the DB is and I'm conscious that those filenames exist there. I think, from what you're saying, that this is, in fact, the purpose of that table - to record which migrations have been run and which have not.
Please or to participate in this conversation.