django migration 的问题

首先 python3 manage.py makemigrations 是会基于 django_migration 表和当前的 model.py 进行的差异对比生成 migrations 文件，执行 migrate 后是根据新增的 migrations 文件执行表结构变更后在 django_migrations 插入对应 migrations 文件对应的 app 信息和时间戳版本信息

所以需要对比 django_migrations 表各 app 执行模块对应最新版本信息、migrations 文件信息、以及对应表结构综合对比

没有反应，总有错误提示吧，没有错误提示？

与题目无关，生产环境不建议用 migrate ，使用 sql 文件管理，一次次更新做好版本控制，表结构的变更需要多个人过目，这样不容易出大锅

先不说 migration 为什么带到生产环境用的问题，生产环境为什么要 makemigrations ，直接把测试环境生产的 migrations 文件跑一遍 migratei 就好了呀。

最佳实践是非生产环境用 django migration 工具，同时 migrations 文件要和 models 文件一起提交到 git ，各种调试和反复确定 model 后合并一下 migrations 问卷只留下个位数的，然后用 sql migratie 命令得到这些 migrations 文件的实际执行 sql ，然后再生产执行这些 sql

migrations 可以提交到仓库里，线上直接执行 migrate 一般没问题，但是你中间有一次断档了，就有点麻烦了

建议将此次改动先 执行 show sqlmigrate 返回 sql ，生产直接跑 sql ，然后对每个改过的 app 执行 fake 迁移， 然后将测试环境迁移表同步到生产，并将 migrations 文件提交到 git ，下次直接 migrate 就可以了

之前也遇到过这样的问题，后面直接再弄一个分支专门用来做 Malians 保证迁移文件干净整洁

prod 用 migration 没问题，问题是 migration 必须只增不减，必须每次进 repo ，不要动 migration 表。

makemigration 生成的 migration 文件提交到 repo 了吗？

```
# sed -i 's/256/255/g' home_application/models.py
# python manage.py makemigrations
No changes detected
```

看来是这个原因

在 django 中正确的操作是：
1 、开发环境随意 makemigration 和 migrate ，需要注意的是每次 makemigration 如果 Model 有变动都会生成一个迁移文件在 migrations 里。
3 、git 提交代码前，还要删除所有新增的 migrations 里的文件，重新 makemigration 生成迁移文件，并使用 migrate --fake ，原因是这样操作会把多个生成的多个迁移文件变成一个，使用--fake 是因为数据库已经更改，并不需要重新更改数据库结构，只会把迁移记录加到数据库里。
4 、版本控制 migrations 文件夹里的文件
5 、正式环境，只做两件事 git pull 和 migrate

建议了解一下 django 迁移文件的原理，并用数据库工具查看一下 django_migrations 这张表，看一下里面有什么，了解 makemigration 、migrate 干了什么，以及--fake 的作用是什么。有能力建议看一下源码。

@founddev 你说的问题我都做过，实际上问题出现在 makemigrations 里不会体现 models 的变更。目前还不清楚原因。

前面有人提到了。就是 makemigrations 只在本地干一次，检查生成的 sql ，本地运行 migration 。线上只运行 migrate ，千万不要线上 makemigrations ，那导致你 migrations 文件错乱，同理，也不要直接去改本地或者线上数据库结构。