python – Sollte das Migrationsverzeichnis des Django-Projekts an Git übergeben werden?

Question

Wie der Titel schon sagt, ändert sich das Modell manchmal mehrmals, wenn die lokale Entwicklungsumgebung es ändert, und dann werden viele Migrationsdateien generiert.

Aber wie soll der Server bei der Bereitstellung auf dem Server Änderungen durchführen:

1. Keine Migrationsdatei hochladen, sondern direkt ausführen makemigrations 重新生成 migrations，再运行 migrate

2. Laden Sie die Migrationsdatei während der Entwicklung hoch und führen Sie sie dann direkt aus migrate

Welche der beiden oben genannten Methoden sollte ich wählen? Warum?

Answer 1

按照官方的说法，应该提交，并且在服务器端应该直接执行 migrate，无需再次生成。

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.

中文翻译：

你可以想象 migrations 相当一个你的数据库的一个版本控制系统。makemigrations 命令负责保存你的模型变化到一个迁移文件 - 和 commits 很类似 - 同时 migrate负责将改变提交到数据库。

每个 app 的迁移文件会保存到每个相应 app 的“migrations”文件夹里面,并且准备如何去执行它, 作为一个分布式代码库。 每当在你的开发机器或是你同事的机器并且最终在你的生产机器上运行同样的迁移，你应当再创建这些文件。

Answer 2

建议提交到版本库中。

Answer 3

我目前是不同步到远程库的。
因为开发过程中要频繁的对model进行修改，会生成很多migrations文件，不好控制migrate不出错；
发布程序之前，首先确认是否进行model更新，如果有的话先进行makemigrations然后migrate，由于本地已经测试完成，所以不容易出现一些奇怪的同步问题。

Answer 4

为什么不提交之前把migrations里新生成的多次变动删了 重新makemigrations一下然后提交版本库呢

Answer 5

可是在本地，添加字段然后再删除等等一些无用的操作，最后可能数据库没有任何变动，那么这些 migrations 也得提交到服务器上再运行一遍？