如果你需要将两个具有相似模型的分支合并或在它们之间进行切换，则这与数据库问题类似，类似于源代码（git）中的合并冲突。没有人故意喜欢它。
想象一下，你上周开始修改应用程序，可能是因为发现了一个错误或者是通过字段或表扩展了该应用程序。今天，你收到了更新，并且遇到了问题，因为存在一个迁移，该迁移添加了仍在数据库中的字段，并且你只能应用该迁移的其他部分。你通过运行查看迁移的SQL内容
./manage sqlmigrate some_app 0007_new_migration >customized-some_app-0007_new_migration.sql
将内容与上周所做的更改进行比较，然后删除或注释掉仍然适用且无法重复的命令。手动运行所有剩余的SQL。标记该迁移将被自动应用：
./manage migrate --fake some_app 0007_new_migration
如果你破坏了某些内容，则没人会帮助你，因为迁移系统将无法进一步了解数据库的当前状态。因此，请进行备份，写笔记，使用沙箱并精确地工作。
编辑：迁移表
django_migrations是在所有应用程序中应用的迁移的简单列表。该表中的行应始终与数据库结构处于同步状态。正常人可以应用迁移
migrate。（或未应用到较旧状态的反向迁移，通常当然会丢失一些数据）虚假迁移仅将更改应用于django_migrations表。
me => select * from django_migrations; id | app | name| applied ----+----------+-------------------------+------------------------------- 1 | some_app | 0001_initial | 2017-10-16 06:11:07.31249+02 2 | some_app | 0002_auto_20171016_1905 | 2017-10-17 02:05:48.979295+02
迁移（文件）是对增量更改的描述，也是可以评估
models.py自上次迁移以来（运行时进行比较）之间差异的信息
makemigrations。在某些表最初未被管理并且以后可以被管理的情况下也足够了。（因此也记录了非托管表。）
编辑：一个示例：如何sqlmigrate使用–fake可以通过迁移来修复损坏的数据库（重新创建已删除的表）。
编辑：示例：如果你决定删除某个应用程序的表，然后通过创建它们migrate，你可能还想通过伪迁移名称“ 零 ” 首先重置该应用程序的所有迁移，包括初始迁移。
./manage migrate –fake some_app zero。
