7
  1. Imagine that I have a branch that has a migration. It's an experimental branch that keeps up with master, but will not be merged into it for a while, if ever.
  2. Master migrations change over time.
  3. The result is that when I merge in master, I end up with multiple migration leaves, meaning that manage.py migrate errors out. If I just do manage.py makemigrations --merge, then it creates a new leaf that will later also be out of date.

Is there a nice way to handle this? I'm tempted just to avoid having any migrations in long-lived dependent branches.

Doug Bradshaw
  • 1,452
  • 1
  • 16
  • 20
  • 2 options I think: do not track your new migrations or their modifications in the non-master branch, and generate the master migrations only once the branch is merged into master. Or merge master migrations into your branch before updating the branch ones, then commit it and merge back the branch into master. – pawamoy Apr 03 '18 at 15:41

1 Answers1

3
  1. Rebase an experimental branch on top of master before merging it.

  2. Unapply all migrations from the experimental branch: 

    manage.py migrate <appname> <previousMigration>

  3. Delete all migrations from the experimental branch.

  4. Create a brand new migration:

    manage.py makemigrations

  5. Commit changes to the experimental branch

  6. Merge the experimental branch.

It's perfectly safe to delete migrations from a repository if no one else has applied them.

Max Malysh
  • 29,384
  • 19
  • 111
  • 115
  • 2
    While helpful, it's important to note that this is only going to work if all of the content of your migrations was automatically generated. If any of the migrations on your experimental branch contain - for example - `migrations.RunPython` operations, they will not be recreated. – Harry Vane Nov 18 '19 at 19:01