You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into individual migration files - analogous to commits - and migrate is responsible for applying those to your database.

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.

schema migrations (automatic)

data migrations (created manually)

• migrate, which is responsible for applying migrations, as well as unapplying and listing their status.
• makemigrations, which is responsible for creating new migrations based on the changes you have made to your models.
• sqlmigrate, which displays the SQL statements for a migration.
• showmigrations, which lists a project’s migrations.

The Commands

Migration files

• dependencies
• operations

how do migrations work ?

https://docs.djangoproject.com/en/1.8/ref/django-admin/#makemigrations-app-label

migrate  / makemigration commands

Why keep migrations in vcs ?

(examples)

• consistency
• rollbacks
• data migrations  (vs commands)

common problem scenarios

• conflicts (merge)
• https://docs.djangoproject.com/en/1.10/howto/writing-migrations/
• http://stackoverflow.com/questions/2224410/django-data-migration-when-changing-a-field-to-manytomany
• git

The End