Menu
As the title says... I'm not sure if Django migrations should live in source control.
For:
Against:
621
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. If you follow this process, you shouldn't be getting any merge conflicts in the migration files.
Short answer: the migrations originate from Django apps and third party apps you installed in INSTALLED_APPS . Not the ones you defined yourself. Migrations are generated per app, and are stored in some_app/migrations .
If you've not created some custom migrations for like loading data, then yes. It should be safe to remove all of the migrations in the migrations folder and run makemigratons command.
Yes, absolutely!!
From the docs:
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.
One big point is that migrations should always be tested before you deploy them in production. You should never create migrations on production, only apply them.
You also want to synchronise the state of the models in source control with the state of the database. If someone pulls your branch, has to find a bug, and goes back in the source control's history, he'd need the migration files to change the state of the database to match that point in time. If he has to create his own migration files, they won't include the intermediate state, and he runs into a problem where his models are out-of-sync with the database.
178
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
