Should I be adding the Django migration files in the
I’ve recently been getting a lot of git issues due to migration conflicts and was wondering if I should be marking migration files as ignore.
If so, how would I go about adding all of the migrations that I have in my apps, and adding them to the
Quoting from the Django migrations documentation:
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.
If you follow this process, you shouldn’t be getting any merge conflicts in the migration files.
To mitigate any issues you currently have, you should specify which repository or branch has the authoritative version of the migration files, and then use git’s attribute mechanism to specify the merge strategy “ours” for these files. This will tell git to always ignore external changes to these files and prefer the local version.
I’ve been over this many times and I can’t, for the life of me, find a case where we need migrations in the repo.
As I see it, the definitive record of the schema is
models.py. If I merge a change and someone else pulls it, all will be correct when they run
migrate. There’s no need to define what the strategy of “ours” is for migrations.
If we need to roll back, then we revert
models and migrate. All good, no problems, ever.
No complaining that a field already exists, etc.
I wonder if anyone can give me a specific case where it’s an advantage for me to have to merge another developer’s migrations files before I can get to work. I know the docs say I should, so I assume it’s so. But I’ve never encountered even one.
You can follow the below process.
You can run
makemigrations locally and this creates the migration file. Commit this new migration file to repo.
In my opinion you should not run
makemigrations in production at all. You can run
migrate in production and you will see the migrations are applied from the migration file that you checked in from local. This way you can avoid all conflicts.
Feels like you’d need to adjust your git workflow, instead of ignoring conflicts.
Ideally, every new feature is developed in a different branch, and merged back with a pull request.
PR cannot be merged if there’s a conflict, therefore who needs to merge his feature needs to resolve the conflict, migrations included.
I can’t imagine why you would be getting conflicts, unless you’re editing the migrations somehow? That usually ends badly – if someone misses some intermediate commits then they won’t be upgrading from the correct version, and their copy of the database will be corrupted.
The process that I follow is pretty simple – whenever you change the models for an app, you also commit a migration, and then that migration doesn’t change – if you need something different in the model, then you change the model and commit a new migration alongside your changes.
In greenfield projects, you can often delete the migrations and start over from scratch with a 0001_ migration when you release, but if you have production code, then you can’t (though you can squash migrations down into one).
The solution usually used, is that, before anything is merged into master, the developer must pull any remote changes. If there’s a conflict in migration versions, he should rename his local migration (the remote one has been run by other devs, and, potentially, in production), to N+1.
During development it might be okay to just not-commit migrations (don’t add an ignore though, just don’t
add them). But once you’ve gone into production, you’ll need them in order to keep the schema in sync with model changes.
You then need to edit the file, and change the
dependencies to the latest remote version.
This works for Django migrations, as well as other similar apps (sqlalchemy+alembic, RoR, etc).