6

We have been working on a django project for months. You know for a dev team, migrations conflicts happen many times. I searched a lot to look what others do with this kind of problem and got results:
What really annoys me about Django migrations
django migrations - workflow with multiple dev branches
Django Migrations and How to Manage Conflicts
How to avoid migration conflicts with other developers?
And many other articles about how to avoid and resolve migration conflicts.
I want to know what if we just ignore migration files and just don't commit them?
Any answer is appreciated.

Sayse
  • 42,633
  • 14
  • 77
  • 146
Ali Farhoudi
  • 5,350
  • 7
  • 26
  • 44
  • 3
    Stop ignoring them. You're only making your life harder. – Sayse Jul 23 '18 at 06:59
  • 1
    Migration conflicts shouldn't be happening at all. You need to try and work out why they are. – Daniel Roseman Jul 23 '18 at 07:05
  • Thanks a lot. But what happens if I just ignore them? In a small project we have ignored it and till now we had no problem. – Ali Farhoudi Jul 23 '18 at 07:21
  • Do you have an alternative plan to keep the database structures consistent across developer and deployment machines? – kristaps Jul 23 '18 at 07:24
  • 1
    Thanks @kristaps. We could easily run `makemigrations` and then `migrate` command in all development and deployment machines. – Ali Farhoudi Jul 23 '18 at 07:38
  • Interesting take on the problem! I guess that would handle structure changes about as well as having migrations. It would probably be more difficult if you need any data transformations along the way. – kristaps Jul 23 '18 at 08:37
  • You've seen what happens if you ignore them, you get headaches – Sayse Jul 23 '18 at 09:20

1 Answers1

4

You should not ignore database migrations. The Django documentation makes this pretty clear (emphasis is mine):

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.

The fact that you have migration conflicts is an indication that your multiple developers are all creating their migrations at different times, resulting in a different set of files. If you commit the migrations as you should, this will never be a problem.

However, if you plan on squashing migrations (e.g. you expect to have a lot of churn in your database schema during a development cycle), you might wait to commit the migrations until all of your database design work for that cycle is complete. But they should always get committed.

After that, everyone will have the same set of files and no more conflicts.

Jonah Bishop
  • 12,279
  • 6
  • 49
  • 74
  • 1
    Thank you for your time to answer the question. You are right. This is the way we have chosen usually and sometimes we get conflicts in our database. I had seen that the django documentation has mentioned that. In another small project we haven't commit migrations yet and we haven't face any problem with migrations. I need to know what is wrong about this approach? – Ali Farhoudi Jul 24 '18 at 06:11
  • Not committing the migrations can yield conflicts between developers, just as you have noticed. By committing migrations as you create them, you will never have those conflicts again. I'm not sure I understand why you *wouldn't* commit those files. They are small, and there shouldn't be that many of them to begin with. – Jonah Bishop Jul 24 '18 at 14:01
  • 1
    No, we do not have conflicts when we do not commit migration files. We just run makemigrations and then migrate commands and there's no conflicts. We have conflicts when we commit migrations, because there are changes in databases that could be removed in another commit. – Ali Farhoudi Jul 25 '18 at 06:55
  • If your migrations are committed to your source tree, everyone is *guaranteed* to have the same database setup as everyone else, because everyone will have the same migrations. You will occasionally have to deal with situations where database changes occur on one branch and not on another, but those situations will likely only happen once in a while. The migration machinery allows you to undo migrations should you need to. – Jonah Bishop Jul 25 '18 at 12:39