Migrations and branches

I would gitignore the sqlite DB and play with the .env files to point to the right file instead (if you need one specific for your branch), less headache.

Hi @mdecooman The issue or point to be aware of is not the sqlite db as I see it, it is the list of migrations is stored in the DB.

So if you move branch to build a new feature, add some migrations (they will be added to the db table and changes)

Then if you switch branch before you need to fold that one back in. The db will contain the migrations in the list but the new branch will not, as the php files for the migration are in a different branch.

So you either need to rebuild the db each time you have a new branch or you need to manage the migrations differently.

Hi @tristanbailey ,

My previous answer was a bit fast (and dumb I must confess ;) Here is a better attempt to answer your questions:

Should you work with a new db for each branch you use?

Personally I wouldn't unless the branch is disruptive enough. I make backups of the DB to keep my sanity (<name-of-the-branch>-datetime.sql).

or maybe some other way

You shouldn't have to 'rebuild' the db each time you have a new feature-branch. Rolling back the migrations done in the current branch before switching is one of the reasons having the migration files. About the data you can have seeders and some relevant SQL exports to keep data for your specific views should a migration:refresh or rebuild be triggered.

Hope this help.

PS: I have this article in my fav: http://codesthq.com/blog/2015/maintaining-database-structure-and-working-on-multiple-branches.html. It is laravel-agnostic but helped me in the same topic.