At Gidsy, we use South to manage our database migrations. It handles a fair amount of edge cases quite well, but every once in a while we still have to sort out things manually. Migrations created concurrently for the same model but on different branches are one of those cases, but we found that the following workflow works pretty good for us.

Let’s assume we have a Django Model called Event in an App called Activity, for which the initial migration 0001_initial was already created and is synced across all development systems. Now Phil decides that each Event should definitely have a city and auto-creates 0002_auto__add_field_city. At the same time, Jannis adds date and category fields on his own branch, creating 0002_auto__add_field_date and 0003_auto__add_field_category. Upon merging Phil’s branch, he notices the conflicting migrations and aborts the merge. With this resolution strategy, the day is saved once again:

1. Roll back the migrations to the last non-conflicting state:

   ./manage.py migrate activity 0001

2. Delete the conflicting migrations in your branch (if you have custom migration code, keep it around somewhere)
3. Merge the remote branch
4. Re-add your migrations

   ./manage.py schemamigration activity --auto

   (Optional: Add your custom migration code)
5. Migrate your database!

Note that all the migrations endemic to your local branch will be squashed into one if you auto-generate them – but we see this mostly as a benefit that speeds up our deployment and local setup times.