33

I'm currently working on a dev branch and I will need to merge it to master one day. I have up to 20 migrations files on my dev branch and about the same number on master at the moment. I needed to make migrations on both branches which will result in migrations having the same prefix,

(ex 0003_auto)

In other words, if you have migrations files generated by makemigrations with the same prefix, what is the best/secure way of handling this.

Here are two ways I have figured myself (maybe entirely wrong):

  1. Deleting all migrations files, merge the code and then running a fresh makemigrations and migrate which will result in only one migration file.

  2. Using the --merge flag to let django make the merge:

    makemigrations --merge

Now, knowing all this I'd like to know what is the best way of handling this. In general, what should I use that will correctly merge conflicts and get me a fresh version of my project with every model updates.

EDIT

I think providing a step by step solution would be ideal for me and future users since there exists tons of informations on the subject but not one seems to be concise and clear.

greggyb
  • 3,728
  • 1
  • 11
  • 32
scharette
  • 9,437
  • 8
  • 33
  • 67
  • Do you have a production database with data? Are you using git? – ikkuh Nov 03 '17 at 14:11
  • I'm still only at dev phase of the project. But it would still be preferable not to delete the database and yes I'm using git. – scharette Nov 03 '17 at 14:14
  • Also, this is my case at the moment, but in general I'm looking for an easy way of doing this. I looked documentation several times but can't find an easy way of handling migrations As I said, the only easy way out of it I found was `--merge` but is this enough ? – scharette Nov 03 '17 at 14:16
  • I would suggest not to push migration files or migration folder on git to avoid any accidental merge conflicts in migration. As it is directly related to your database – Shikhar Thapliyal Nov 03 '17 at 14:25
  • Delete migrations, revert databse to master branch, merge code, makemigrations and migrate to see if you don't have migration issues. But why do you commit the migrations files, that files depends ont the state of the databse. – jalanga Nov 03 '17 at 14:25
  • 1
    This is from the Django official documentation : _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._ – scharette Nov 03 '17 at 14:30
  • So I should not be remoting migrations files is that what you guys are saying ? – scharette Nov 03 '17 at 14:32
  • 6
    You are unfortunately getting some very bad advice in these comments. Like the docs say, migrations are part of your code base and *must* be committed to version control and deployed. You must not run makemigrations in production. – Daniel Roseman Nov 03 '17 at 16:29
  • However, having multiple migrations with the same prefix is not in itself a problem. Django keeps a record of what has been run, and will run the missing ones only. – Daniel Roseman Nov 03 '17 at 16:30
  • So, if I run migrate with multiples files with the same prefix, it will pass ? – scharette Nov 03 '17 at 16:34

4 Answers4

29

From the Django docs:

Because migrations are stored in version control, you’ll occasionally come across situations where you and another developer have both committed a migration to the same app at the same time, resulting in two migrations with the same number.

Don’t worry - the numbers are just there for developers’ reference, Django just cares that each migration has a different name [emphasis added].

Community
  • 1
  • 1
ostergaard
  • 3,377
  • 2
  • 30
  • 40
6

The simplest way to do this without any worry is this:

  1. Revert to a stable point (before conflicts):

python manage.py migrate usersmaster 0021_signup_status

  1. Delete new migration files.

  2. Re-make migrations:

python manage.py makemigrations

Moradnejad
  • 3,466
  • 2
  • 30
  • 52
  • makemigrations may probably create just the same files that were deleted on the step 2. This mean you could just omit steps 2 and 3. Also, new migration files could be written by hand. – belkka Oct 22 '20 at 21:11
  • 1
    No @belkka. When you recreate a migration file it will create just one migration file for all the changes (not all the migration files from stable points till now that were deleted). However, we should take care not to delete the migration files created by others otherwise there will be a mess for them. They will have those deleted migration files in their branch and your branch won't. Merging both branches will create nasty problems. – Kundan Kumar Jun 03 '22 at 07:29
1

When you are ready, you should merge from master to your development branch. At that time you should fix all conflicts, your migrations should go after master's migrations, and after all of that your database should look as you want it be like.

Since that process takes time, and is quite painful, most people consider short living development branches. That way you need to deal with one or two migration files at a time.

Michał Zaborowski
  • 3,911
  • 2
  • 19
  • 39
0

You can resolve migration errors using django-migration-fixer

Fixing migrations on your dev branch can be done using

$ git checkout [dev-branch]
$ git merge [main/master]

Follow the installation instructions here

Run

$ python manage.py makemigrations --fix -b [main/master]

commit the changes and push to the remote branch

$ git add .
$ git commit -am ...
$ git push ...
cxxl
  • 4,939
  • 3
  • 31
  • 52
jackotonye
  • 3,537
  • 23
  • 31