使用 Django South 重置迁移历史的推荐方法是什么？

如果您需要有选择地（仅针对一个应用程序）重置耗时过长的迁移，this 对我有用。

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

不要忘记手动恢复其他应用程序上的任何 dependencies，方法是将 depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial")) 之类的行添加到您的 <app-dir>/migrations/0001_initial.py 文件中，作为迁移类中 class Migration(SchemaMigration): 下方的第一个属性。

然后，您可以按照 this SO answer 在其他环境中./manage.py migrate <app-name> --fake --delete-ghost-migrations。当然，如果您伪造删除或伪造 migrate zero，您需要手动删除任何剩余的数据库表，如 this 迁移。

更核心的选项是在实时部署服务器上使用 ./manage.py migrate --fake --delete-ghost-migrations，然后是 [my]sqldump。然后在需要迁移的、完全填充的数据库的环境中将该转储通过管道传输到 [my]sql 中。南方的亵渎，我知道，但对我有用。

---

编辑-我在下面的顶部发表评论，因为在@andybak @Dominique 后面的>接受答案之前阅读它很重要：您关于manage.py reset south的建议是危险的，如果有可能会破坏数据库正如下面@thnee 所指出的，在项目中使用 south 的任何第三方应用程序。由于您的答案有很多赞成票，如果您可以对其进行编辑并至少添加一个警告，或者（甚至更好）将其更改为反映@hobs方法（这同样方便，但不影响其他应用程序） - 谢谢！ – chrisv 2013 年 3 月 26 日 9:09 接受的答案如下：

首先，an answer by the South author：

只要您注意同时在所有部署上执行此操作，就不会出现任何问题。就个人而言，我会这样做： rm -r appname/migrations/ ./manage.py reset south ./manage.py convert_to_south appname （请注意，“reset south”部分会清除所有应用程序的迁移记录，因此请确保您要么运行所有应用程序的其他两行或有选择地删除）。最后的 convert_to_south 调用会进行新的迁移并伪造应用它（因为您的数据库已经有相应的表）。在此过程中无需删除所有应用程序表。

当我需要摆脱所有这些不需要的开发迁移时，这就是我在开发 + 生产服务器上所做的事情：

确保我们在两边都有相同的数据库模式删除两边的每个迁移文件夹在两边运行./manage.py reset south（如帖子所说）=清除南表*在两边运行./manage.py convert_to_south双方（伪造0001迁移）然后我可以重新开始进行迁移并将迁移文件夹推送到我的服务器上

除非您只想清理其中一个应用程序，否则您需要编辑 south_history 表并仅删除有关您的应用程序的条目。

---

感谢多米尼克瓜迪奥拉和霍布斯的回答，它帮助我解决了一个难题。但是，该解决方案存在一些问题，这是我的看法。

如果您有任何使用 South 的第三方应用程序，例如 django-cms（基本上所有应用程序都使用 South），则使用 manage.py reset south 不是一个好主意。

reset south 将删除您已安装的所有应用程序的所有迁移历史记录。

现在考虑升级到最新版本的 django-cms，它将包含新的迁移，如 0009_do_something.py。当您尝试在迁移历史记录中没有 0001 到 0008 的情况下尝试运行该迁移时，South 肯定会感到困惑。

仅选择性地重置您正在维护的应用程序会更好/更安全。

首先，确保您的应用程序在磁盘上的迁移和已在数据库上执行的迁移之间没有任何不同步。不然会头疼。

1. 删除我的应用程序的迁移历史记录

sql> delete from south_migrationhistory where app_name = 'my_app';

2. 删除我的应用程序的迁移

$ rm -rf my_app/migrations/

3. 为我的应用创建新的初始迁移

$ ./manage.py schemamigration --initial my_app

4. 假执行我的应用程序的初始迁移

这会将迁移插入 south_migrationhistory 而不触及实际表：

$ ./manage.py migrate --fake my_app

第 3 步和第 4 步实际上只是 manage.py convert_to_south my_app 的一个较长的变体，但我更喜欢这种额外的控制，在修改生产数据库这样微妙的情况下。

---

就像 thnee（请参阅她的回答）一样，我们对此处其他地方引用的南方作者 (Andrew Godwin) 的建议使用了一种更温和的方法，并且我们在部署期间将我们对代码库所做的事情与我们对数据库所做的事情分开，因为我们需要部署是可重复的：

我们在代码中做了什么：

# Remove all the migrations from the app
$ rm -fR appname/migrations
# Make the first migration (don't touch the database)
$ ./manage.py schemamigration appname --initial

部署该代码后，我们对数据库执行的操作

# Fake the migration history, wiping out the rest
$ ./manage.py migrate appname --fake --delete-ghost-migrations

---

如果您只是在开发机器上工作，我编写了一个管理命令，它几乎可以执行 Dominique 的建议。

http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html

与南作者的建议相反，这不会伤害使用南的其他已安装应用程序。

---

以下仅当您要重置所有应用程序时。请在该工作之前备份您的所有数据库。如果有的话，还要在初始文件中记下您的 depends_on。

一次：

(1) find . -type d -name migrations -exec git rm -rf '{}' \;
(2) find . -type d -name migrations -exec rm -rf '{}' \;
(3) ./manage.py schemamigration <APP_NAME> --initial
(4) [GIT COMMIT]

在推送之前测试引导您的项目。然后，对于每台本地/远程机器，应用以下内容：

(5) [GIT PULL]
(6) ./manage.py reset south
(7) ./manage.py migrate --fake

为您要重新参与的每个应用程序执行初始 (3)。请注意，reset (6) 将仅删除迁移历史记录，因此对库无害。虚假迁移 (7) 将放回已安装的任何第 3 方应用程序的迁移历史记录。

---

从应用程序文件夹中删除必要的文件

实例路径

 cd /usr/local/lib/python2.7/dist-packages/wiki/south_migrations

wiki - 是我的应用程序

---