python - django 项目的 migrations 目录是否应该提交到 git

问题描述

如题，本地开发环境修改 model 时，有些时候会变动好几次，然后就生成了很多 migrations 文件。

但是部署到服务器时，服务器端应该怎么执行变动：

不上传 migrations 文件，直接执行 makemigrations 重新生成 migrations，再运行 migrate

上传开发时的 migrations 文件，然后直接执行 migrate

上面两种方法该选哪一种？为什么？

问题解答

按照官方的说法，应该提交，并且在服务器端应该直接执行 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”文件夹里面,并且准备如何去执行它, 作为一个分布式代码库。 每当在你的开发机器或是你同事的机器并且最终在你的生产机器上运行同样的迁移，你应当再创建这些文件。

建议提交到版本库中。

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

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

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