我已经使用Django大约2年了，我一直害怕使用的一个功能：伪造迁移。
我到处都看了很多，我能获得的最多信息是从文档中获得的，该文档指出：
– fake
告诉Django将迁移标记为已应用或未应用，但没有实际运行SQL来更改数据库架构。
如果高级用户手动应用更改，则可以直接操作当前迁移状态。请注意，使用–fake冒着将迁移状态表置于需要手动恢复以使迁移正确运行的状态的风险。
–fake-initial
如果使用该迁移中所有CreateModel操作创建的所有模型的所有数据库表均已存在，则允许Django跳过应用程序的初始迁移。此选项适用于首次对已预先使用迁移的数据库运行迁移时使用。但是，此选项不会检查匹配表名称之外的匹配数据库架构，因此只有在确信现有架构与初始迁移中记录的内容相匹配时，才可以安全使用。
我得到了一般的想法，以及为什么要使用此功能。但是，我不明白它所说的部分仅适用于高级用户。
有人可以解释一下幕后发生的事情以及为什么需要手动恢复。
注意
我不是在寻找伪造迁移时运行的确切原始SQL查询。我只是在寻找幕后发生的一般情况，也许是为什么伪造迁移会导致状态makemigrations无法正常工作的示例。
makemigrations
如果你需要将两个具有相似模型的分支合并或在它们之间进行切换，则这与数据库问题类似，类似于源代码（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表。
django_migrations
migrate
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。在某些表最初未被管理并且以后可以被管理的情况下也足够了。（因此也记录了非托管表。）
models.py
编辑：一个示例：如何sqlmigrate使用–fake可以通过迁移来修复损坏的数据库（重新创建已删除的表）。
编辑：示例：如果你决定删除某个应用程序的表，然后通过创建它们migrate，你可能还想通过伪迁移名称“ 零 ” 首先重置该应用程序的所有迁移，包括初始迁移。 ./manage migrate –fake some_app zero。
