您可以做的另一件事是删除手动创建的表。

与此同时，您还必须删除特定的迁移文件。同时，你必须删除django-migrations表中与特定迁移相关的特定条目(可能是你的情况下的最后一个)。

在恢复之前不要删除迁移文件。我犯了这个错误，没有迁移文件，数据库就不知道要删除什么东西。

python manage.py showmigrations
python manage.py migrate {app name from show migrations} {00##_migration file.py}

如果你想恢复所有的迁移，使用0作为迁移的名称:

python manage.py migrate app_name_here zero

删除迁移文件。一旦您的模型中有了所需的迁移……

python manage.py makemigrations
python manage.py migrate

Alasdair的回答涵盖了基本问题

通过./manage.py showmigrations确定您想要的迁移 使用应用程序名称和迁移名称进行迁移

但应该指出的是，并非所有的迁移都可以逆转。如果Django没有规则来执行反转，就会发生这种情况。对于通过./manage.py makemigrations自动进行迁移的大多数更改，反转是可能的。然而，自定义脚本将需要同时写正向和反向，如示例中所述:

https://docs.djangoproject.com/en/1.9/ref/migration-operations/

如何进行无操作逆转

如果您有一个RunPython操作，那么您可能只是想在不编写逻辑上严格的反转脚本的情况下退出迁移。下面对文档中的示例的快速修改(上面的链接)允许这样做，使数据库保持在应用迁移之后的相同状态，即使是在反转它之后。

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations, models

def forwards_func(apps, schema_editor):
    # We get the model from the versioned app registry;
    # if we directly import it, it'll be the wrong version
    Country = apps.get_model("myapp", "Country")
    db_alias = schema_editor.connection.alias
    Country.objects.using(db_alias).bulk_create([
        Country(name="USA", code="us"),
        Country(name="France", code="fr"),
    ])

class Migration(migrations.Migration):

    dependencies = []

    operations = [
        migrations.RunPython(forwards_func, lambda apps, schema_editor: None),
    ]

这适用于Django 1.8、1.9

更新:更好的编写方法是将上面代码片段中的lambda apps, schema_editor: None替换为migrations.RunPython.noop。它们在功能上是一样的。(来源:评论)

有一个很好的库可以使用它叫djagno-nomad，虽然没有直接关系到所问的问题，想分享这个，

场景:大多数情况下，当切换到项目时，我们觉得它应该恢复我们在当前分支上所做的更改，这正是这个库所做的，下面签出

https://pypi.org/project/django-nomad/

这个答案适用于类似的情况，如果Alasdair给出的最上面的答案没有帮助。(例如，如果不需要的迁移很快在每次新的迁移中再次创建，或者如果它是在一个更大的迁移中，不能恢复，或者表已经被手动删除。)

删除迁移，而不创建新的迁移?

TL;DR:您可以删除一些最后恢复的(混乱的)迁移，并在修复模型后进行一个新的迁移。您还可以使用其他方法将其配置为不通过migrate命令创建表。必须创建最后一个迁移，以便与当前模型匹配。

为什么任何人都不想为必须存在的模型创建表:

A)在任何机器、任何数据库和任何条件下都不应该存在这样的表

当:仅为继承其他模型而创建的基础模型。 解决方法:设置类Meta: abstract = True

B)该表很少创建，由其他东西或手动以特殊方式创建。

解决方案:使用类Meta: managed = False 迁移已经创建，但从未使用，仅在测试中使用。迁移文件很重要，否则数据库测试无法从可重现的初始状态开始运行。

C)该表只在某些机器上使用(例如在开发中)。

解决方案:将模型移动到仅在特殊条件下才添加到INSTALLED_APPS的新应用程序中，或者使用条件类Meta: managed = some_switch。

D)该项目在设置中使用多个数据库。数据库

解决方案:使用allow_migrate方法编写一个数据库路由器，以便区分应该在哪里创建表和不应该在哪里创建表的数据库。

The migration is created in all cases A), B), C), D) with Django 1.9+ (and only in cases B, C, D with Django 1.8), but applied to the database only in appropriate cases or maybe never if required so. Migrations have been necessary for running tests since Django 1.8. The complete relevant current state is recorded by migrations even for models with managed=False in Django 1.9+ to be possible to create a ForeignKey between managed/unmanaged models or to can make the model managed=True later. (This question has been written at the time of Django 1.8. Everything here should be valid for versions between 1.8 to the current 2.2.)

如果最后一次迁移(are)不容易可逆，那么可以谨慎地(在数据库备份后)做一个假恢复。/manage.py migrate——fake my_app 0010_previous_migration，手动删除表。

如果有必要，从固定的模型创建一个固定的迁移，并在不改变数据库结构的情况下应用它。

您可以做的另一件事是删除手动创建的表。

与此同时，您还必须删除特定的迁移文件。同时，你必须删除django-migrations表中与特定迁移相关的特定条目(可能是你的情况下的最后一个)。