django migrations - workflow with multiple dev branches

Migrations rollback are possible and usually handled automatically by django.

Considering the following model:

class MyModel(models.Model):    pass

If you run python manage.py makemigrations myapp, it will generate the initial migration script.You can then run python manage.py migrate myapp 0001 to apply this initial migration.

If after that you add a field to your model:

class MyModel(models.Model):        my_field = models.CharField()

Then regenerate a new migration, and apply it, you can still go back to the initial state. Just run python manage.py migrate myapp 0001 and the ORM will go backward, removing the new field.

It's more tricky when you deal with data migrations, because you have to write the forward and backward code.Considering an empty migration created via python manage.py makemigrations myapp --empty,you'll end up with something like:

# -*- coding: utf-8 -*-from __future__ import unicode_literalsfrom django.db import models, migrationsdef forward(apps, schema_editor):    # load some data    MyModel = apps.get_model('myapp', 'MyModel')    while condition:        instance = MyModel()        instance.save()def backward(apps, schema_editor):    # delete previously loaded data    MyModel = apps.get_model('myapp', 'MyModel')    while condition:        instance = MyModel.objects.get(myargs)        instance.delete()class Migration(migrations.Migration):    dependencies = [        ('myapp', '0003_auto_20150918_1153'),    ]    operations = [         migrations.RunPython(forward, backward),    ]

For pure data-loading migrations, you usually don't need the backward migration. But when you alter the schema and update existing rows,
(like converting all values in a column to slug), you'll generally have to write the backward step.

In our team, we try to avoid working on the same models at the same time to avoid collision.If it is not possible, and two migration with the same number (e.g 0002) are created,you can still rename one of them to change the order in will they will be applied (also remember to update the dependencies attribute on the migration class to your new order).

If you end up working on the same model fields at the same time in different features,you'll still be in trouble, but it may means these features are related and should be handledtogether in a single branch.

For the git-hooks part, it's probably possible to write something, Assuming your are on branch mybranch and want to check out another feature branch myfeature:

1. Just before switching, you dump the list of currently applied migrations intoa temporary file mybranch_database_state.txt
2. Then, you apply myfeature branch migrations, if any
3. Then, when checking back mybranch, you reapply your previous database stateby looking to the dump file.

However, it seems a bit hackish to me, and it would probably be really difficult to handle properly all scenarios:rebasing, merging, cherry-picking, etc.

Handling the migrations conflicts when they occurs seems easier to me.

I don't have a good solution to this, but I feel the pain.

A post-checkout hook will be too late. If you are on branch A and you check out branch B, and B has fewer migrations than A, the rollback information is only in A and needs to be run before checkout.

I hit this problem when jumping between several commits trying to locate the origin of a bug. Our database (even in development trim) is huge, so dropping and recreating isn't practical.

I'm imagining a wrapper for git-checkout that:

1. Notes the newest migration for each of your INSTALLED_APPS
2. Looks in the requested branch and notes the newest migrations there
3. For each app where the migrations in #1 are farther ahead than in #2, migrate back to the highest migration in #2
4. Check out the new branch
5. For each app where migrations in #2 were ahead of #1, migrate forward

A simple matter of programming!

For simple changes I rely on migration rollback, as discussed by Agate.

However, if I know a feature branch is going to involve highly invasive database changes, or if it will involve a lot of data migration, I like to create a clone of the local (or remote dev) database as soon as I start the new branch. This may not always be convenient, but especially for local development using sqlite it is just a matter op copying a file (which is not under source control).

The first commit on the new branch then updates my Django settings (local/dev) to use the cloned database. This way, when I switch branches, the correct database is selected automatically. No need to worry about rolling back schema changes, missing data, etc. No complicated stuff.

After the feature branch has been fully merged, the cloned database can be removed.