The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.
...
Once the migration is applied, commit the migration and the models change to your version control system as a single commit - that way, when other developers (or your production servers) check out the code, they’ll get both the changes to your models and the accompanying migration at the same time.
[ ] We should remove the makemigrations invocation from the /app/init.py script and follow the recommended workflow.
According to the Django documentation about the workflow for creating and applying database migrations:
makemigrations
invocation from the/app/init.py
script and follow the recommended workflow.