我已经成为Django的用户大约两年了，并且有一个我一直害怕使用的功能： 伪造迁移 。
我几乎到处都看了，我能得到的最多信息来自documentation，其中说明：
- 假
告诉Django将迁移标记为已应用或 未应用，但没有实际运行SQL来更改您的 数据库架构。
这适用于高级用户操纵当前 如果他们手动应用更改，则直接迁移状态;是 警告说使用--fake会冒着迁移状态的风险 表进入需要手动恢复的状态 迁移正确运行。
- 假初始
如果所有数据库都允许Django跳过应用程序的初始迁移 表格，其中包含所有CreateModel创建的所有模型的名称 该迁移中的操作已经存在。此选项是有意的 用于首次针对数据库运行迁移时使用 预先存在使用迁移。但是，此选项不会检查 用于匹配数据库模式以及匹配表名称等等 只有在您确信现有架构时才能安全使用 匹配初始迁移中记录的内容。
我得到了一般的想法以及为什么要使用此功能。但是，我不理解这个部分只是 仅供高级用户使用。
有人可以解释幕后发生的事情以及为什么需要手动恢复。
注意
我没有寻找伪造迁移时运行的确切原始SQL查询。我只是在寻找关于场景背后发生的事情的一般概念，也许是为什么假装迁移的一个例子
会导致makemigrations无法正常工作的状态。
答案 0 :(得分：14)
想象一下，您上周开始修改应用程序，可能是因为您发现了一个错误，或者您是通过字段或列扩展它。今天您收到了更新，但是您遇到了问题，因为有一个迁移会添加一个仍在您的数据库中的字段，并且您只能应用该迁移的其他部分。您可以通过运行
来查看其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 是所有应用中应用迁移的简单列表。此表中的行应始终与数据库结构处于同步状态。可以通过正常迁移来应用迁移。 （或通过反向迁移到旧状态而不应用，当然通常会丢失一些数据）虚假迁移仅将更改应用于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
迁移（文件）是增量变更的描述，以及在运行makemigrations时可以评估自上次迁移以来模型差异的信息。在最初未管理某些表并且稍后可以管理它们的情况下也足够了。
编辑 sqlmigrate和--fake如何用于fix a broken database by migrations（重新创建已删除的表格）的示例。