24

As the title says... I'm not sure if Django migrations should live in source control.

For:

  • If they get accidentally deleted from my local machine, it's going to cause me issues next time I want to run a migration... right? So it would be useful for me to have them.

Against:

  • Devs setting up the project for the first time shouldn't need to run them, they can just work straight from the models file.
  • They seem like machine-specific cruft.
  • Could they potentially reveal things I don't want about the database?
Richard
  • 62,943
  • 126
  • 334
  • 542
  • Does this answer your question? [Should I be adding the Django migration files in the .gitignore file?](https://stackoverflow.com/questions/28035119/should-i-be-adding-the-django-migration-files-in-the-gitignore-file) – toraritte Jan 20 '23 at 17:23
  • Related: (1) [**Why** push migrations to VCS? (`stackoverflow`)](https://stackoverflow.com/questions/32376092/why-there-is-need-to-push-django-migrations-to-version-control-system); (2) Tips about managing conflicts: [Is it really important to save django's migrations in a version control system? (`dev.to`)](https://dev.to/simo97/is-it-really-important-to-save-djangos-migrations-in-a-version-control-system--5d03); (3) Info on _squashing_ migrations: [How do you guys manage git + migrations? (`reddit`)](https://www.reddit.com/r/django/comments/msm26e/how_do_you_guys_manage_git_migrations/) – toraritte Jan 20 '23 at 17:29

1 Answers1

35

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.

knbk
  • 52,111
  • 9
  • 124
  • 122
  • 4
    I'm wrestling with this same question. If two developers fork the migration history, merging those conflicts can get messy. Without migrations, those conflicts don't happen. To knbk 's first point, simply create and test migrations in a staging env. To knbk 's second point, this concern is real, but it seems easier to deal with than migration conflicts. –  Sep 24 '16 at 01:53
  • I've just deployed my first app to Heroku. Although the app deployed successfully, the database migration had a NodeNotFoundError which was caused by the fact my Migrations folder was not in source control. Once I added my migrations to my GitHub repo, I was able to migrate the database to Heroku – Mark__C Mar 14 '18 at 20:43