python - Should the migrations directory of the django project be committed to git

Question

As the title states, when the local development environment modifies the model, sometimes it changes several times, and then many migrations files are generated.

But when deployed to the server, how should the server perform changes:

1. Do not upload migrations files, directly execute makemigrations Regenerate migrations, and then run migrate

2. Upload the migrations file during development and then execute it directly migrate

Which one should I choose among the above two methods? Why?

Answer 1

According to the official statement, it should be submitted and migrate should be executed directly on the server side without the need to generate it again.

You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into inpidual migration files - analogous to commits - and migrate is responsible for applying those to your database.

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.

Chinese translation:

You can think of migrations as a version control system for your database. The makemigrations command is responsible for saving your model changes to a migration file - much like commits - while migrate is responsible for committing the changes to the database.

The migration file of each app will be saved in the "migrations" folder of each corresponding app, and how to execute it will be prepared as a distributed code base. You should create these files again every time you run the same migration on your development machine or your colleague's machine and eventually on your production machine.

Answer 2

It is recommended to submit it to the repository.

Answer 3

I am currently not synchronizing to the remote library.
Because the model needs to be modified frequently during the development process, many migration files will be generated, and it is difficult to control the migration without errors;
Before publishing the program, first confirm whether the model is updated. If so, first perform makemigrations and then migrate. Due to local It's been tested, so it's not prone to some weird sync issues.

Answer 4

Why don’t you delete the newly generated changes in migrations before submitting, re-makemigrations and then submit the repository

Answer 5

But locally, adding fields and then deleting them, etc. are some useless operations. In the end, there may be no changes in the database. So these migrations also have to be submitted to the server and run again?