我已经使用 South (0.7) 和 Django (1.1.2) 积累了相当多的迁移，这些迁移在我的单元测试中开始消耗相当多的时间。我想重置基线并开始一组新的迁移。我已经查看了South 文档，完成了通常的 Google/Stackoverflow 搜索（例如“django south（重置或删除或删除）迁移历史”）并且没有发现任何明显的东西。
我考虑过的一种方法是通过“删除” South 或手动“清除”历史记录来“重新开始”（例如清除 db 表，从迁移目录中删除迁移文件），然后重新运行，
./manage.py schemamigration southtut --initial
因此，如果有人以前这样做过并且有一些提示/建议，他们将不胜感激。
如果您需要有选择地（仅针对一个应用程序）重置花费太长时间的迁移，这对我有用。
rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake --delete-ghost-migrations
不要忘记通过在文件中添加行来手动恢复对其他应用程序的任何依赖关系，作为迁移类中的第一个属性，就在下面。depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial"))<app-dir>/migrations/0001_initial.pyclass Migration(SchemaMigration):
然后，您可以./manage.py migrate <app-name> --fake --delete-ghost-migrations根据此 SO answer在其他环境中使用。当然，如果你伪造删除或伪造，migrate zero你需要手动删除任何剩余的数据库表，像这样的迁移。
一个更核心的选择是./manage.py migrate --fake --delete-ghost-migrations在实时部署服务器上，然后是 [my] sqldump。然后在需要迁移的、完全填充的数据库的环境中将该转储通过管道传输到 [my]sql 中。南方的亵渎，我知道，但对我有用。
编辑 - 我在下面的顶部发表评论，因为在 @andybak 之后的 > 接受的答案之前阅读它很重要
@Dominique：您关于 manage.py reset south 的建议很危险，如果项目中有任何第三方应用程序使用 south，则可能会破坏数据库，如下面的 @thnee 所指出的。由于您的答案有很多赞成票，如果您可以对其进行编辑并至少添加一个警告，或者（甚至更好）将其更改为反映@hobs方法（这同样方便，但不影响其他应用程序） - 谢谢！– chrisv 2013 年 3 月 26 日在 9:09
接受的答案如下：
首先，南方作者的回答：
只要您注意同时在所有部署上执行此操作，就不会出现任何问题。就个人而言，我会这样做：
rm -r appname/migrations/ ./manage.py reset south ./manage.py convert_to_south appname（请注意，“<code>reset south”部分会清除所有应用程序的迁移记录，因此请确保为所有应用程序运行其他两行或有选择地删除）。
最后的
convert_to_south调用会进行新的迁移并伪造应用它（因为您的数据库已经有相应的表）。在此过程中无需删除所有应用程序表。
当我需要摆脱所有这些不需要的开发迁移时，这就是我在开发 + 生产服务器上所做的事情：
* 除非您只想清理其中一个应用程序，否则您需要编辑 south_history 表并仅删除有关您的应用程序的条目。
感谢多米尼克瓜迪奥拉和霍布斯的回答，它帮助我解决了一个难题。但是，该解决方案存在一些问题，这是我的看法。
例如，如果您有任何使用 South 的第三方应用程序（基本上所有应用程序都使用 South） ，则使用manage.py reset south不是一个好主意。django-cms
reset south将删除您已安装的所有应用程序的所有迁移历史记录。
现在考虑升级到最新版本django-cms，它将包含新的迁移，例如0009_do_something.py. 0001当您尝试在未完成0008迁移历史的情况下运行该迁移时，South 肯定会感到困惑。
仅选择性地重置您正在维护的应用程序会更好/更安全。
首先，确保您的应用程序在磁盘上的迁移和已在数据库上执行的迁移之间没有任何不同步。不然会头疼。
sql> delete from south_migrationhistory where app_name = 'my_app';
$ rm -rf my_app/migrations/
$ ./manage.py schemamigration --initial my_app
这将迁移插入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
Following is only if you want to reset all apps. Please backup your all databases prior to that work. Also note down your depends_on in initial files if there are any.
For once:
(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]
Test bootstrapping your project before push. Then, for each local/remote machine, apply following:
(5) [GIT PULL]
(6) ./manage.py reset south
(7) ./manage.py migrate --fake
Do initial (3) for each app you want to re-involve. Note that, reset (6) will delete only migration history, therefore not harmful to libraries. Fake migrations (7) will put back migration history of any 3rd party apps installed.
如果您只是在开发机器上工作，我编写了一个管理命令，它几乎可以执行 Dominique 的建议。
http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html
与南作者的建议相反，这不会伤害使用南的其他已安装应用程序。
从应用程序文件夹中删除必要的文件
实例路径
cd /usr/local/lib/python2.7/dist-packages/wiki/south_migrations
wiki - 是我的应用程序