场景：将项目衍生另一版本，大部分逻辑未改变。创建数据库时应保留 django_migrations django_content_type auth_permission 三个表数据，因某些原因未保存，导致后来执行新的migrate时发生错误
django_migrations 表保留的是历史migrate数据，如果数据为空，就会从一个migrations文件开始执行，而数据库结构是直接拷贝的。所以会报一些表，字段等已存在错误
将原表数据复制到新数据库中解决
场景：执行migrate时遇见新的错误 django.db.utils.InterityError:duplicate key value violates unique constraint ‘django_migrations_pkey’ DETAIL:key(id=1) already exists。
再次执行一遍 报错 某表某字段 already exists，正是migrations文件中将要插入的。
postgresql的隐式id是自增的，由一个tablename_id_seq记录，由于数据库中的Sequences插入从１开始所以出现了第一个错误，但是此时数据库字段更改已经完成了，所以出现了第二个错误，每次执行sequences都是自动加１的，所以如果离正确值只差１的话再执行一次就没事了，但是如果差值较大的话就得修改tablename_id_seq中的记录了。
相关知识扩增：
PostgreSQL之Sequence序列
PostgreSQL如何为主键创建自增序列(Sequences)
修复操作：
select max(id) from django_migrations;查看django_migrations表的最大id，那么此时sequences的正确值应该是最大值加１，SELECT setval('django_migrations_id_seq', (SELECT MAX(id) FROM django_migrations)+1)，这样就将数据的sequences重置正常了，下次就不会继续出错了。
更多的解决方案再上面的问题搜索链接中可以找到。
  通过查看数据库，发现migrations文件中要添加的字段已经添加了，但由于两次migrate操作都报了错，所以在Django看来，该migrations文件就是未执行成功的。
  通过`python manage.py showmigtations ` 查看全部migrations文件执行状态。
[x] 代表已经执行完毕的migrations文件， []表示未执行或执行失败的文件。
命令后可接 app_name 查看某个app下的执行情况。
对于上面确定已执行过的migrations文件可以使用 python manage.py migrate app_name --fake 处理一下。
