使用已应用的迁移应用South迁移

Question

在我们项目的主分支中，我们的一个django应用程序的迁移如下所示：

# ...
(*) 0022_datamigration_1
(*) 0023_datamigration_2
(*) 0024_datamigration_3
(*) 0025_datamigration_4

如您所见，这些迁移已应用于我们的生产系统。在我的一个分支中，我开发了一个需要大量迁移的功能：

(*) 0022_datamigration_1
( ) 0023_my_schemamigration_1
(*) 0023_datamigration_2
( ) 0024_my_datamigration_1
(*) 0024_datamigration_3
(*) 0025_datamigration_4
( ) 0025_my_datamigration_2
( ) 0026_my_schemamigration_2
# ... some more not yet applied schemamigrations
( ) 0030_my_datamigration_x

这又是生产数据库的“迁移历史记录”，但由于我在主要更改时同时处理了我的功能，因此已经应用了一些迁移，现在我在历史记录中有这些“缺口”。 South将通过运行python manage.py migrate my_app

拒绝应用它们

 ! Migration my_app:0024_datamigration_3 should not have been applied before my_app:0024_my_datamigration_1 but was.
 ! Migration my_app:0023_datamigration_2 should not have been applied before my_app:0023_my_schemamigration_1 but was.

如何摆脱那些“迁移差距”（我想我用错误的关键词给谷歌喂食）？至少，迁移应该都会影响不同的模型，所以我想有可能以某种方式做到这一点。

Answer 1

首先，如果您在提交新代码之前整合迁移，那么您将为自己省去一些麻烦。假设您在开发过程中生成了编号为0023,0024和0025的schemamigrations。在提交任何内容之前，您应该在开始进行更改之前回滚到迁移（在这种情况下为0022）：

python manage.py migrate someapp 0022

然后，删除三次迁移，最后生成一个新的schemamigration：

python manage.py schemamigration --auto someapp

现在，您只进行了一次迁移0023，并将所有更改合并在一起。这样可以更轻松地将迁移合并到其余部分中。

然后，当你进行合并时，可能已经有了0023，例如

0023_someone_elses_migration.py
0023_my_migration.py

只需将您的号码重命名为最多一个号码（如果现在一直迁移到0030，则将您的号码重命名为0031）。 然后，提交合并的代码。

一般而言，良好的开发实践应该规定在任何给定时间只有一个开发人员可以处理任何代码库。它不是总是可能，但一般情况下，如果您正在处理“someapp”中的某些功能，并且需要在“someapp”中对其他内容进行错误修复，那么你< / em>应该是那样做的人。即使更改将在完全不同的分支中进行，您也可以通过将更改合并到您正在处理的任何其他内容来进行补偿，而另一个开发人员则不会有任何线索。