问题的原因：

在Django 1.7版本中，进行数据库迁移时可能会遇到一些问题，例如旧的迁移文件或数据库文件不再需要，但仍保留在项目中，导致迁移过程复杂化。

解决方法：

一个解决方法是使用一个脚本来简化迁移过程。下面是一个示例脚本，可以删除旧的迁移文件、数据库文件，并重新生成新的迁移文件和数据库。

#!/bin/sh
echo "Starting ..."
echo ">> Deleting old migrations"
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc"  -delete
# Optional
echo ">> Deleting database"
find . -name "db.sqlite3" -delete
echo ">> Running manage.py makemigrations"
python manage.py makemigrations
echo ">> Running manage.py migrate"
python manage.py migrate
echo ">> Done"

上述脚本使用了`find`命令来删除旧的迁移文件和数据库文件。同时，还删除了`.pyc`文件以确保干净的迁移过程。

需要注意的是，这个脚本会删除相关的数据，而不仅仅是迁移文件。如果不需要删除数据库文件，可以将删除数据库的部分注释掉。

参考链接：[http://unixhelp.ed.ac.uk/CGI/man-cgi?find](http://unixhelp.ed.ac.uk/CGI/man-cgi?find)

在Django 1.7版本的迁移中，与South中的重置功能相比，引入了新的“合并”迁移功能。这被认为是控制迁移数量的好方法。如果你仍然想从头开始，你可以清空迁移表并删除迁移，然后再次运行makemigrations命令。

那么如何“删除迁移”，除了清空迁移表之外还需要删除哪些文件呢？可以删除整个迁移文件夹，当再次运行makemigrations命令时，它会被重新创建。我猜在Django 1.7中也是这样处理的。

需要注意的是，在Django 1.7中，如果不小心删除迁移文件夹，可能会引发异常，特别是当你的模型是另一个模型的子模型时，会出现raise KeyError("Migration %s dependencies reference nonexistent parent node %r" % (migration, parent))的异常。

具体来说，./manage.py squashmigrations myapp 0004命令将合并应用程序myapp中迁移文件0004之前的所有迁移，生成一个合并后的迁移文件。

如何简化Django 1.7中的迁移？

某些情况下了这个问题。我刚刚弄明白了这个问题，这个解决方法是好的。

首先，清除迁移表：

./manage.py migrate --fake <app-name> zero

删除app-name/migrations/文件夹或其内容。

进行迁移：

./manage.py makemigrations <app-name>

最后，在不进行其他数据库更改的情况下整理迁移：

./manage.py migrate --fake <app-name>

这是一个好的答案。只是删除迁移文件并不能撤销任何有问题的迁移所造成的损害。这实际上是清空了现有的迁移，让您可以重新开始。

按照这种方式操作，需要同时删除编号的迁移文件吗？

这行代码只是逐个反向执行迁移，直到zero。对于Django的迁移系统来说，<app-name>现在是一个新的app了，makemigrations <app-name>将从0001开始。使用--fake可以防止实际修改表，迁移只会被标记为反向迁移而不会实际应用于模式。（为了完整性的缘故，我添加了一些解释，-rokk）

问题是，它并没有完全重置。我添加了一个大的模型，即使在使用--fake之后，它也要求每个字段的默认值。

你能添加一些文档吗？zero是什么意思？

manage.py migrate --fake <app-name> zero用于清除迁移表，然后删除<app-name>/migrations/文件夹或其内容。然后执行manage.py makemigrations <app-name>，最后执行manage.py migrate --fake <app-name>。这将整理您的迁移，而不会进行其他数据库更改。

注意：我用优秀的评论补充了原始答案的一行。这个对话的某些部分已经不再相关。