blocks|key|3818148|text|您可以通过migrating+to+the+previous+migration恢复。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3818149|例如，如果您的最后两个迁移是：|3818150|3818151|0010_previous_migration|unordered-list-item|style|CODE|3818152|0011_migration_to_revert|3818153|3818154|然后，您将执行以下操作：|3818155|./manage.py+migrate+my_app+0010_previous_migration+|code-block|syntax|javascript|3818156|您实际上不需要使用完整的迁移名称，数量就足够了，即|3818157|./manage.py+migrate+my_app+0010+|3818158|然后，您可以删除迁移0011_migration_to_revert。|3818159|如果您正在使用Django+1.8%2B，您可以使用以下命令显示所有迁移的名称|3818160|./manage.py+showmigrations+my_app|3818161|要反转应用程序的所有迁移，您可以运行：|3818162|./manage.py+migrate+my_app+zero|3818163|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.djangoproject.com/en/3.2/topics/migrations/#reversing-migrations^0|5|Z|0|0|0|0|0|N|0|0|O|0|0|0|0|0|0|A|O|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@$A|1I|B|1J|1|1K]]|C|$]]|$1|D|3|E|5|6|7|1L|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1N|8|@$A|1O|B|1P|J|K]]|9|@]|C|$]]|$1|L|3|M|5|I|7|1Q|8|@$A|1R|B|1S|J|K]]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1U|8|@]|9|@]|C|$]]|$1|Q|3|R|5|S|7|1V|8|@]|9|@]|C|$T|U]]|$1|V|3|W|5|6|7|1W|8|@]|9|@]|C|$]]|$1|X|3|Y|5|S|7|1X|8|@]|9|@]|C|$T|U]]|$1|Z|3|10|5|6|7|1Y|8|@$A|1Z|B|20|J|K]]|9|@]|C|$]]|$1|11|3|12|5|6|7|21|8|@]|9|@]|C|$]]|$1|13|3|14|5|S|7|22|8|@]|9|@]|C|$T|U]]|$1|15|3|16|5|6|7|23|8|@]|9|@]|C|$]]|$1|17|3|18|5|S|7|24|8|@]|9|@]|C|$T|U]]|$1|19|3|-4|5|6|7|25|8|@]|9|@]|C|$]]]|1A|$1B|$5|1C|1D|1E|C|$1F|1G]]]]

You can revert by <a href="https://docs.djangoproject.com/en/3.2/topics/migrations/#reversing-migrations" rel="noreferrer">migrating to the previous migration</a>.
For example, if your last two migrations are:
<ul>
<li><code>0010_previous_migration</code></li>
<li><code>0011_migration_to_revert</code></li>
</ul>
Then you would do:
<pre><code>./manage.py migrate my_app 0010_previous_migration 
</code></pre>
You don't actually need to use the full migration name, the number is enough, i.e.
<pre><code>./manage.py migrate my_app 0010 
</code></pre>
You can then delete migration <code>0011_migration_to_revert</code>.
If you're using Django 1.8+, you can show the names of all the migrations with
<pre><code>./manage.py showmigrations my_app
</code></pre>
To reverse all migrations for an app, you can run:
<pre><code>./manage.py migrate my_app zero
</code></pre>

blocks|key|1472164|text|您可以做的另一件事是删除手动创建的表。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1472165|随之而来的是，您必须删除该特定迁移文件。此外，您还必须在django-migrations表(可能是您的案例中的最后一个)中删除与该特定迁移相关的特定条目。|1472166|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The other thing that you can do is delete the table created manually. 

Along with that, you will have to delete that particular migration file. Also, you will have to delete that particular entry in the django-migrations table(probably the last one in your case) which correlates to that particular migration.

blocks|key|5234922|text|Alasdair的答案涵盖了基础知识|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5234923|5234924|使用应用程序名称和迁移名称|unordered-list-item|5234925|通过确定您想要的迁移|5234926|但应该指出的是，并不是所有的迁移都是可逆的。如果Django没有反转规则，就会发生这种情况。对于您通过./manage.py+makemigrations自动进行迁移的大多数更改，将有可能进行逆转。但是，自定义脚本需要同时编写正向和反向代码，如下面的示例所述：|offset|length|style|CODE|5234927|https://docs.djangoproject.com/en/1.9/ref/migration-operations/|5234928|如何进行无操作的反转|5234929|如果您有一个RunPython操作，那么您可能只想退出迁移，而不是编写逻辑上严格的反转脚本。文档(上面的链接)中对示例的以下快速修改允许这样做，使数据库处于应用迁移后的相同状态，即使在反向迁移之后也是如此。|5234930|#+-*-+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),
++++]|code-block|syntax|javascript|5234931|这适用于Django+1.8、1.9|5234932|5234933|更新:更好的方法是在上面的代码片段中用migrations.RunPython.noop替换lambda+apps,+schema_editor:+None。这两者在功能上是一样的。(评论的功劳)|5234934|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|1F|Q|0|0|1R|0|0|0|6|9|0|0|0|0|J|P|1A|W|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1C|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@$J|1F|K|1G|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1H|8|@]|9|@$J|1I|K|1J|1|1K]]|A|$]]|$1|P|3|Q|5|6|7|1L|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1M|8|@$J|1N|K|1O|L|M]]|9|@]|A|$]]|$1|T|3|U|5|V|7|1P|8|@]|9|@]|A|$W|X]]|$1|Y|3|Z|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1S|8|@$J|1T|K|1U|L|M]|$J|1V|K|1W|L|M]]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|O]]]]

The answer by Alasdair covers the basics

<ul>
<li>Identify the migrations you want by <code>./manage.py showmigrations</code></li>
<li><code>migrate</code> using the app name and the migration name</li>
</ul>

But it should be pointed out that not all migrations can be reversed. This happens if Django doesn't have a rule to do the reversal. For most changes that you automatically made migrations by <code>./manage.py makemigrations</code>, the reversal will be possible. However, custom scripts will need to have both a forward and reverse written, as described in the example here:

<a href="https://docs.djangoproject.com/en/1.9/ref/migration-operations/">https://docs.djangoproject.com/en/1.9/ref/migration-operations/</a>

<h2>How to do a no-op reversal</h2>

If you had a <code>RunPython</code> operation, then maybe you just want to back out the migration without writing a logically rigorous reversal script. The following quick hack to the example from the docs (above link) allows this, leaving the database in the same state that it was after the migration was applied, even after reversing it.

<pre class="lang-python prettyprint-override"><code># -*- 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),
 ]
</code></pre>

This works for Django 1.8, 1.9

<hr>

Update: A better way of writing this would be to replace <code>lambda apps, schema_editor: None</code> with <code>migrations.RunPython.noop</code> in the snippet above. These are both functionally the same thing. (credit to the comments)

blocks|key|3818260|text|我在1.9.1中做到了这一点(删除上次或最近创建的迁移)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3818261|3818262|rm+<appname>/migrations/<migration+#>*|ordered-list-item|offset|length|style|CODE|3818263|3818264|示例:将rm+myapp/migrations/0011*|3818265|logged导入数据库并运行此SQL+(本例中为postgres)|unordered-list-item|3818266|3818267|delete+from+django_migrations+where+name+like+'0011%25';|3818268|然后，我能够创建以我刚刚删除的迁移号(在本例中为11)开始的新迁移。|3818269|entityMap^0|0|0|0|12|0|0|4|P|0|0|0|0|1I|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Y|8|@$F|Z|G|10|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@$F|13|G|14|H|I]]|9|@]|A|$]]|$1|M|3|N|5|O|7|15|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|17|8|@$F|18|G|19|H|I]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|V|$]]

I did this in 1.9.1 (to delete the last or latest migration created):

<ol>
<li><code>rm &lt;appname&gt;/migrations/&lt;migration #&gt;*</code>

example: <code>rm myapp/migrations/0011*</code></li>
<li>logged into database and ran this SQL (postgres in this example)

<code>delete from django_migrations where name like '0011%';</code></li>
</ol>

I was then able to create new migrations that started with the migration number that I had just deleted (in this case, 11).

blocks|key|1708001|text|这是我的解决方案，因为当您使用RunPython时，上面的解决方案并没有真正涵盖用例。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1708002|您可以使用以下命令通过ORM访问表|1708003|from+django.db.migrations.recorder+import+MigrationRecorder

>>>+MigrationRecorder.Migration.objects.all()
>>>+MigrationRecorder.Migration.objects.latest('id')
Out[5]:+<Migration:+Migration+0050_auto_20170603_1814+for+model>
>>>+MigrationRecorder.Migration.objects.latest('id').delete()
Out[4]:+(1,+{u'migrations.Migration':+1})|code-block|syntax|javascript|1708004|因此，您可以查询表并删除与您相关的条目。这样你就可以进行详细的修改。对于RynPython迁移，您还需要处理添加/更改/删除的数据。上面的示例仅显示了如何通过Djang+ORM访问表。|1708005|entityMap^0|F|9|0|0|0|10|9|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|U|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|P|$]]

Here is my solution, since the above solution do not really cover the use-case, when you use <code>RunPython</code>.

You can access the table via the ORM with

<pre><code>from django.db.migrations.recorder import MigrationRecorder

&gt;&gt;&gt; MigrationRecorder.Migration.objects.all()
&gt;&gt;&gt; MigrationRecorder.Migration.objects.latest('id')
Out[5]: &lt;Migration: Migration 0050_auto_20170603_1814 for model&gt;
&gt;&gt;&gt; MigrationRecorder.Migration.objects.latest('id').delete()
Out[4]: (1, {u'migrations.Migration': 1})
</code></pre>

So you can query the tables and delete those entries that are relevant for you. This way you can modify in detail. With <code>RynPython</code> migrations you also need to take care of the data that was added/changed/removed. The above example only displays, how you access the table via Djang ORM.

blocks|key|5235059|text|如果Alasdair的最高答案不能帮助，则此答案适用于类似的情况。(例如，如果不需要的迁移很快就会在每次新迁移时再次创建，或者如果它处于无法恢复的较大迁移中，或者该表已被手动删除。)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5235060|5235061|+...delete迁移，而不创建新的迁移？|blockquote|5235062|5235063|5235064|TL;DR：您可以删除一些上次恢复(混淆)的迁移，并在修复模型之后创建一个新的。您也可以使用其他方法通过命令将其迁移配置为不创建表。必须创建最后一个迁移，使其与当前型号的相匹配。|offset|length|style|BOLD|5235065|5235066|Cases为什么每个人都不想为必须存在的模型创建表：|5235067|A)+No这样的表不应该存在于没有机器和条件的数据库中|5235068|+Set+When:它是仅为其他model.|5235069|Solution:+Set+class+Meta:+abstract+=+True|unordered-list-item|CODE|5235070|的模型继承而创建的基础模型|5235071|B)表格很少创建，是由其他东西创建的，或者是以特殊方式手动创建的。|5235072|5235073|解决方案:使用class+Meta:+managed+=+False|5235074|5235075|迁移已创建，但从未使用，仅在测试中使用。迁移文件很重要，否则数据库测试将无法从可重现的初始状态开始运行。|5235076|C)该表仅在某些机器上使用(例如在开发中)。|5235077|5235078|解决方案:将模型移动到仅在特殊条件下添加到INSTALLED_APPS的新应用程序，或使用有条件的a|5235079|5235080|D)项目在settings.DATABASES中使用多个数据库|5235081|5235082|解决方案:使用allow_migrate方法编写一个Database+router，以便区分应该在何处创建表的数据库以及不应该在何处创建表的数据库。|5235083|5235084|5235085|迁移在所有情况下都是使用Django+1.9%2B创建的A)、B)、C)、D)+(并且仅在使用Django+1.8的情况下B、C、D)，但仅在适当的情况下才应用于数据库，或者如果需要的话，可能从不应用。从Django+1.8开始，必须进行迁移才能运行测试。迁移记录了完整的相关当前状态，即使是在Django+1.9%2B中使用managed=False的模型，也可以在托管/非托管模型之间创建ForeignKey，或者可以在以后创建模型managed=True。(这个问题在Django+1.8的时候已经写好了。这里的所有内容都应该适用于1.8到当前的2.2之间的版本。)|5235086|如果最后一次迁移不容易恢复，那么可以谨慎地(在数据库备份之后)执行fake+revert+./manage.py+migrate+--fake+my_app+0010_previous_migration，手动删除该表。|5235087|如有必要，从固定模型创建固定迁移，并在不更改数据库结构./manage.py+migrate+--fake+my_app+0011_fixed_migration的情况下应用它。|5235088|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.djangoproject.com/en/1.11/topics/db/multi-db/#automatic-database-routing|1|https://stackoverflow.com/q/46772762/448474^0|0|0|0|0|0|0|5|V|8|0|0|0|5|0|0|2|0|0|E|R|0|0|0|2|0|0|7|R|0|0|0|0|2|0|0|0|0|0|2|5|I|0|0|7|D|Q|F|0|0|0|0|0|19|1L|X|B|1|0|R|1I|0^^$0|@$1|2|3|4|5|6|7|21|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|23|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|25|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|26|8|@$J|27|K|28|L|M]|$J|29|K|2A|L|M]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|2C|8|@$J|2D|K|2E|L|M]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|2F|8|@$J|2G|K|2H|L|M]]|9|@]|A|$]]|$1|S|3|T|5|6|7|2I|8|@]|9|@]|A|$]]|$1|U|3|V|5|W|7|2J|8|@$J|2K|K|2L|L|X]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|2M|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2N|8|@$J|2O|K|2P|L|M]]|9|@]|A|$]]|$1|12|3|-4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|13|3|14|5|W|7|2R|8|@$J|2S|K|2T|L|X]]|9|@]|A|$]]|$1|15|3|-4|5|6|7|2U|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2V|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2W|8|@$J|2X|K|2Y|L|M]]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|W|7|30|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|31|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|32|8|@$J|33|K|34|L|M]|$J|35|K|36|L|X]]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|37|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|W|7|38|8|@$J|39|K|3A|L|X]]|9|@$J|3B|K|3C|1|3D]]|A|$]]|$1|1J|3|-4|5|6|7|3E|8|@]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|3F|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|3G|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|6|7|3H|8|@$J|3I|K|3J|L|X]]|9|@$J|3K|K|3L|1|3M]]|A|$]]|$1|1P|3|1Q|5|6|7|3N|8|@$J|3O|K|3P|L|X]]|9|@]|A|$]]|$1|1R|3|-4|5|6|7|3Q|8|@]|9|@]|A|$]]]|1S|$1T|$5|1U|1V|1W|A|$1X|1Y]]|1Z|$5|1U|1V|1W|A|$1X|20]]]]

This answer is for similar cases if the top answer by Alasdair does not help. (E.g. if the unwanted migration is created soon again with every new migration or if it is in a bigger migration that can not be reverted or the table has been removed manually.)

<blockquote>
 ...delete the migration, without creating a new migration?
</blockquote>

TL;DR: You can delete a few last reverted (confused) migrations and make a new one after fixing models. You can also use other methods to configure it to not create a table by migrate command. The last migration must be created so that it match the current models.

<hr>

Cases why anyone do not want to create a table for a Model that must exist:

A) No such table should exist in no database on no machine and no conditions

<ul>
<li>When: It is a base model created only for model inheritance of other model.</li>
<li>Solution: Set <code>class Meta: abstract = True</code></li>
</ul>

B) The table is created rarely, by something else or manually in a special way.

<ul>
<li>Solution: Use <code>class Meta: managed = False</code> 
The migration is created, but never used, only in tests. Migration file is important, otherwise database tests can't run, starting from reproducible initial state.</li>
</ul>

C) The table is used only on some machine (e.g. in development).

<ul>
<li>Solution: Move the model to a new application that is added to INSTALLED_APPS only under special conditions or use a conditional <code>class Meta: managed = some_switch</code>.</li>
</ul>

D) The project uses multiple databases in <code>settings.DATABASES</code>

<ul>
<li>Solution: Write a <a href="https://docs.djangoproject.com/en/1.11/topics/db/multi-db/#automatic-database-routing" rel="nofollow noreferrer">Database router</a> with method <code>allow_migrate</code> in order to differentiate the databases where the table should be created and where not.</li>
</ul>

<hr>

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.)

If the last migration is (are) not easily revertible then it is possible to cautiously (after database backup) do a <a href="https://stackoverflow.com/q/46772762/448474">fake revert</a> <code>./manage.py migrate --fake my_app 0010_previous_migration</code>, delete the table manually.

If necessary, create a fixed migration from the fixed model and apply it without changing the database structure <code>./manage.py migrate --fake my_app 0011_fixed_migration</code>.

blocks|key|3818545|text|如果您在恢复迁移时遇到问题，并且不知何故搞砸了，您可以执行fake迁移。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3818546|./manage.py+migrate+<name>+--ignore-ghost-migrations+--merge+--fake|code-block|syntax|javascript|3818547|对于小于1.7的django版本，这将在south_migrationhistory表中创建条目，您需要删除该条目。|BOLD|3818548|现在，您将能够轻松地恢复迁移。|3818549|PS:我被困了很长一段时间，执行假迁移，然后恢复过来帮助我摆脱了困境。|3818550|entityMap^0|T|4|0|0|8|1E|K|M|0|0|F|0|0|Z|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|W|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|X|8|@$9|Y|A|Z|B|M]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|12|8|@$9|13|A|14|B|M]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|15|8|@$9|16|A|17|B|M]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|S|$]]

If you are facing trouble while reverting back the migration, and somehow have messed it, you can perform <code>fake</code> migrations.

<pre><code>./manage.py migrate &lt;name&gt; --ignore-ghost-migrations --merge --fake
</code></pre>

For django version &lt; 1.7 this will create entry in <code>south_migrationhistory</code> table, you need to delete that entry.

Now you'll be able to revert back the migration easily.

PS: I was stuck for a lot of time and performing fake migration and then reverting back helped me out.

blocks|key|1472265|text|在恢复之前不要删除迁移文件。我犯了这个错误，没有迁移文件，数据库就不知道要删除什么东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1472266|python+manage.py+showmigrations
python+manage.py+migrate+{app+name+from+show+migrations}+{00##_migration+file.py}|code-block|syntax|javascript|1472267|If+you+want+to+revert+all+migrations，请使用zero作为迁移的名称：|offset|length|style|CODE|1472268|python+manage.py+migrate+app_name_here+zero|1472269|删除迁移文件。一旦所需的迁移在您的模型中...|1472270|python+manage.py+makemigrations
python+manage.py+migrate|1472271|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.djangoproject.com/en/3.1/topics/migrations/#reversing-migrations^0|0|0|14|4|0|10|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|12|8|@$I|13|J|14|K|L]]|9|@$I|15|J|16|1|17]]|A|$]]|$1|M|3|N|5|D|7|18|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1A|8|@]|9|@]|A|$E|F]]|$1|S|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

Don't delete the migration file until after the reversion. I made this mistake and without the migration file, the database didn't know what things to remove.
<pre><code>python manage.py showmigrations
python manage.py migrate {app name from show migrations} {00##_migration file.py}
</code></pre>
<a href="https://docs.djangoproject.com/en/3.1/topics/migrations/#reversing-migrations" rel="noreferrer">If you want to revert all migrations</a>, use <code>zero</code> as the name of the migration:
<pre><code>python manage.py migrate app_name_here zero
</code></pre>
Delete the migration file. Once the desired migration is in your models...
<pre><code>python manage.py makemigrations
python manage.py migrate
</code></pre>

blocks|key|5235169|text|您可以通过迁移到以前的迁移来恢复。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5235170|例如，使用以下命令：|5235171|./manage.py+migrate+example_app+one_left_to_the_last_migration|code-block|syntax|javascript|5235172|然后删除last_migration文件。|offset|length|style|CODE|5235173|entityMap^0|0|0|0|4|E|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@$K|U|L|V|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

You can revert by migrating to the previous migration.
For example use below command:
<pre><code>./manage.py migrate example_app one_left_to_the_last_migration
</code></pre>
then delete <code>last_migration</code> file.

blocks|key|3818651|text|有一个很好的库可以使用它的名为djagno-nomad，尽管与所问的问题没有直接关系，但我想分享这个，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3818652|场景:大多数情况下，当切换到项目时，我们认为它应该恢复我们在当前分支上所做的更改，这正是这个库所做的，请查看下面的内容|3818653|https://pypi.org/project/django-nomad/|offset|length|3818654|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|12|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@$F|R|G|S|1|T]]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|E]]]]

there is a good library to use its called djagno-nomad, although not directly related to the question asked, thought of sharing this,
scenario: most of the time when switching to project, we feel like it should revert our changes that we did on this current branch, that's what exactly this library does, checkout below
<a href="https://pypi.org/project/django-nomad/" rel="nofollow noreferrer">https://pypi.org/project/django-nomad/</a>

blocks|key|1472302|text|要恢复迁移，请执行以下操作：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1472303|python+manage.py+migrate+<APP_NAME>+<MIGRATION_NUMBER_PREFIX>|code-block|syntax|javascript|1472304|MIGRATION_NUMBER_PREFIX是您要恢复到的迁移的号码前缀，例如，0001用于转到0001_initial.py迁移。然后，您可以删除该迁移。|offset|length|style|CODE|1472305|1472306|您可以使用zero作为迁移编号来恢复应用程序的所有迁移。|blockquote|1472307|1472308|entityMap^0|0|0|0|N|15|4|1D|F|0|0|5|4|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|U|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|V|8|@$I|W|J|X|K|L]|$I|Y|J|Z|K|L]|$I|10|J|11|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|13|8|@$I|14|J|15|K|L]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|S|$]]

To revert a migration:
<pre><code>python manage.py migrate &lt;APP_NAME&gt; &lt;MIGRATION_NUMBER_PREFIX&gt;
</code></pre>
<code>MIGRATION_NUMBER_PREFIX</code> is the number prefix of the migration you want to revert to, for instance <code>0001</code> to go to <code>0001_initial.py</code> migration. then you can delete that migration.
<blockquote>
You can use <code>zero</code> as your migration number to revert all migrations of an app.
</blockquote>

blocks|key|3818730|text|首先:找到你的应用程序之前的迁移，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3818731|python+mange.py+showmigrations|offset|length|style|CODE|3818732|例如：|BOLD|3818733|bz
+[X]+0001_initial
+[+]+0002_bazifff|code-block|syntax|javascript|3818734|如果要回滚0002_bazifff迁移，|3818735|python+manage.py+migrate+bz+0001_initial|3818736|如果您想要回滚0001_initial或all|3818737|python+manage.py+migrate+bz+zero|3818738|似乎无法仅回滚0001|3818739|entityMap^0|0|0|U|0|0|3|0|0|5|C|0|0|14|0|7|C|K|3|0|0|W|0|7|4|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@$D|16|E|17|F|J]]|9|@]|A|$]]|$1|K|3|L|5|M|7|18|8|@]|9|@]|A|$N|O]]|$1|P|3|Q|5|6|7|19|8|@$D|1A|E|1B|F|J]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1C|8|@$D|1D|E|1E|F|G]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1F|8|@$D|1G|E|1H|F|J]|$D|1I|E|1J|F|J]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1K|8|@$D|1L|E|1M|F|G]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1N|8|@$D|1O|E|1P|F|J]]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|10|$]]

First: find the previous migrations of your app,
<code>python mange.py showmigrations</code>
eg:
<pre><code>bz
 [X] 0001_initial
 [ ] 0002_bazifff


</code></pre>
If you want rollback 0002_bazifff migrations,
<code>python manage.py migrate bz 0001_initial</code>
If you want rollback 0001_initial Or all
<code>python manage.py migrate bz zero</code>
It seems can't rollback 0001 only

blocks|key|1472343|text|所有其他答案都适用于回滚线性迁移。然而，当迁移是非线性的，即有多个叶子节点，并且我们希望只回滚一条路径时，我们可以通过以下方式进行：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1472344|++++X
++/+++\
+A++++++B++++++[A+and+B+can+represent+any+number+of+linear+migrations.]+
++\+++/
++++Y+(merge+migration)|code-block|syntax|javascript|1472345|如果我们需要回滚A，B和Y，那么我们可以像其他答案状态那样做。即python+manage.py+migrate+app+X。|offset|length|style|CODE|1472346|但是，如果只需要取消应用一条路径，即回滚B和Y，请执行以下步骤：|1472347|通过暂时从项目位置python+manage.py+migrate+app+B+(or+A;+both+works).|1472348|Remove迁移文件A和Y，|unordered-list-item|1472349|仅取消应用Y。|ordered-list-item|1472350|现在通过执行python+manage.py+migrate+app+X.|1472351|取消应用B|1472352|1472353|将迁移文件A和Y移至原始位置。现在，如果愿意，您可以安全地删除未应用的迁移B和Y。|1472354|的要点是，django只能回滚迁移，前提是文件存在于该位置。如果您不想回滚迁移路径(即此处为A)，请在执行回滚时将其从项目位置删除。|BOLD|1472355|entityMap^0|0|0|W|U|0|0|9|1D|0|0|0|6|U|0|0|0|0|0|1U|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1A|8|@$I|1B|J|1C|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|1D|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1E|8|@$I|1F|J|1G|K|L]]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1H|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1I|8|@]|9|@]|A|$]]|$1|W|3|X|5|V|7|1J|8|@$I|1K|J|1L|K|L]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1M|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1O|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1P|8|@$I|1Q|J|1R|K|15]]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]]|17|$]]

All the other answers work great for rolling back linear migrations. However, when the migration is non-linear i.e has multiple leaf nodes and we wish to rollback only one path, then we can do in following way:
<pre><code> X
 / \
 A B [A and B can represent any number of linear migrations.] 
 \ /
 Y (merge migration)
</code></pre>
If we need to rollback A,B and Y. Then we can do the way other answer states.
i.e <code>python manage.py migrate app X</code>.
However, if need to only unapply one path i.e, rollback B and Y, perform following steps:
<ol>
<li>Unapply only Y. By doing <code>python manage.py migrate app B (or A; both works)</code>.</li>
<li>Remove the migration files A and Y for time being from the project location.</li>
<li>Now unapply B, by doing <code>python manage.py migrate app X</code>.</li>
</ol>
Bring the migration files A and Y to the original location. Now, you can safely delete the unapplied migrations B and Y, if you wish to.
The gist is django can only rollback migrations if the files are present in the location. If you do not want to rollback a migration path (i.e A here), remove it from the project location while performing rollback.

I've made a migration that added a new table and want to revert it and delete the migration, without creating a new migration.

How do I do it? Is there a command to revert last migration and then I can simply delete the migration file?

How to revert the last migration?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我进行了一次迁移，添加了一个新表，并希望恢复并删除迁移，而不创建新的迁移。我该怎么做呢？是否有恢复上次迁移的命令，然后我可以简单地删除迁移文件？

问如何恢复上一次迁移？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何恢复上一次迁移？EN