Django/ Python- should I run makemigrations on a local branch, or only on master?

Question

I am working on a project that has been written in Python/ Django, and have recently made some changes to one of the models . I want to test the changes that I have made now, before I go any further into the development of this new feature, but I am aware that I will need to run python manage.py makemigrations & python manage.py migrate before the changes that I have made to the models take effect.

I am doing the development on a separate git branch to master , but am a bit unsure what the best practice is here in terms of running migrations on different branches (I am relatively new to both Python/ Django & Git).

Would it be sensible to run makemigrations on my development branch, and testing it there, the same way I have been testing the bug fixes that I have worked on so far, or will I need to merge my development branch with master before running makemigrations ?

I know that if I do run the migrations on my development branch, I will need to run them again on master once I have merged my changes, but I was just wondering if there are any dangers to this approach, or things I should look out for?

Answer 1

Generally, you would do a makemigrations on your development branch, and you would move the code (in this case, migration files) up to higher branches (UAT, Staging, Master etc).

This way you would never need to run makemigrations on any other branch, but only the migrate command.

You can have as many migration files as you need, it doesn't really affect performance and is highly optimised

You can always squash/merge your migrations if there are too many or if you wish to do so.

See Squasing Migrations

Answer 2

Running makemigrations will automatically create python files in the "migrations" folder of the app where you modified the model. These files must be versionned in git because they cannot be dissociated from your modifications of the model.

Then, when you will merge your branch, both the modification in the model and the corresponding migration will be in the git tree. So the next call to migrate will synchronize the DB with the current state described by your models.