4

在我们项目的 master 分支中，我们的一个 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

这又是生产数据库的“迁移历史”，但由于我在更改 master 时同时处理我的功能，因此已经应用了一些迁移，现在我在历史中存在这些“空白”。南方将通过运行来拒绝应用它们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.

我怎样才能摆脱那些“迁移差距”（我想我给谷歌提供了错误的关键字）？至少，迁移应该都会影响不同的模型，所以我想有可能以某种方式做到这一点。

4

1 回答 1

3

首先，如果您在提交新代码之前合并迁移，您会省去很多麻烦。假设您在开发过程中生成了编号为 0023、0024 和 0025 的架构迁移。在提交任何内容之前，您应该在开始进行更改之前回滚到迁移（在本例中为 0022）：

python manage.py migrate someapp 0022

然后，删除你的三个迁移，最后生成一个新的架构迁移：

python manage.py schemamigration --auto someapp

现在，您只有一个迁移 0023，其中包含您所做的所有更改。这使得将您的迁移合并到其余部分变得更加容易。

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

0023_someone_elses_migration.py
0023_my_migration.py

只需将您的数字重命名为比最大值大一（如果现在有迁移一直到 0030，您可以将您的数字重命名为 0031）。然后，提交合并的代码。

但是，一般来说，良好的开发实践应该规定在任何给定时间只有一名开发人员在任何代码库上工作。这并不总是可能的，但总的来说，如果您正在处理“someapp”中的某些功能，并且需要对“someapp”中的其他内容进行错误修复，那么您应该是这样做的人。即使更改将在完全不同的分支中进行，您也可以通过将更改合并回您正在处理的任何其他内容来进行补偿，而其他开发人员则不知道。

于 2012-06-21T20:06:15.793 回答