我已经成为Django的用户大约2年了，并且有一个我一直害怕使用的功能：伪造迁移。
我几乎到处都看了，我能得到的最多信息来自documentation，它说明：
- 假
告诉Django将迁移标记为已应用或未应用，但没有实际运行SQL来更改数据库架构。
这适用于高级用户在手动应用更改时直接操作当前迁移状态;请注意，使用--fake会冒着将迁移状态表置于需要手动恢复以使迁移正确运行的状态的风险。
--fake-初始
如果所有具有该迁移中所有CreateModel操作创建的模型名称的数据库表已存在，则允许Django跳过应用程序的初始迁移。此选项适用于首次针对预先存在使用迁移的数据库运行迁移时使用。但是，此选项不会检查匹配的表名称之外的匹配数据库模式，因此只有在您确信现有模式与初始迁移中记录的模式匹配时才可以安全使用。
我得到了一般的想法以及为什么人们想要使用这个功能。但是，我不明白它所说的部分仅适用于高级用户。
有人可以解释幕后发生的事情以及为什么需要手动恢复。
注意
我不是在寻找伪造迁移时运行的确切原始SQL查询。我只是在寻找关于场景背后发生的事情的一般概念，也许是为什么伪造迁移会导致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表。
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可以用于fix a broken database by migrations（重新创建一个删除的表）。