Hi all,
-- The way I've always worked, developers run `makemigrations` locally, and commit migration files to the repo.
However, a suggestion has recently come my way that a better strategy is to only commit model changes to the repo (leaving the migrations directory gitignored), and then run `makemigrations` in whatever environment the app needs to run, whether that's another developer's laptop, or in production. The putative benefit is that this avoids the possibility of migration conflicts, and always guarantees a clean migration from the state of a database schema to the state of the Django models.
Googling around, this opinion seems to be moderately widespread, although the official docs, and the *majority* of commenters seem to agree that committing migration files is the right way.
I think I agree, but I can't quite put my finger on decisive arguments against the idea of not committing migration files. I feel like I am missing something.
What are some reasons we should go the route of committing migration files?
Thanks,
Tom
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/08ef20a1-9b51-4bea-a1d8-7d3ed61093fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment