将 Django South 与多个代码分支一起使用的工作流程

Question

我很好奇其他 Django 开发人员在使用多个代码分支进行开发时如何使用 South 管理他们的数据库迁移。让我给出一个示例场景。

例如，假设您从主干开始开发。您从主干创建分支 A。此时，app_1 的最后一个迁移版本是 0010。

然后您在创建迁移文件0011_add_name_column 的主干中为app_1 创建迁移。同时，在分支 A 中，另一个开发人员为分支 A 中的同一 app_1 创建了不同的迁移文件：0011_increase_value_column_size。

分支 A 最终合并回主干。发生这种情况时，假设分支 A 中 app_1 中的最后一个迁移版本是 0020，而在主干中的最后一个版本是 0018，它们都是不同的迁移。如您所见，自版本0011 以来，迁移文件的状态已经混乱，当时分支是从主干分叉出来的......并且它们在合并时都存在冲突。

根据South's tutorial，处理这种情况的唯一方法是手动解决所有冲突。但是，如果冲突的数量很大，这并不是真正需要的解决方案。您通常如何处理这种情况，甚至一开始就避免这种情况？

Answer 1

嗯，这个问题的答案不是很简单。

TL；DR 更新： 在大多数情况下，如果我们谈论的是 Trunk Branch 工作流程，我可能会

1. 将分支 A 中的新迁移“压缩”为单个迁移（或最少可能）
2. 将所有主干更改/迁移合并到分支 A。
3. 重命名分支 A 迁移到 0019 等等。
4. 现在合并到主干。

更多细节

首先，如果您有多个具有相同前缀（即0011）的迁移来自合并不同的分支，这并不重要，只要它们不修改相同的模型。然后，您可以简单地使用 --merge 选项运行 migrate 来应用乱序迁移。

但是，如果您有两个不同的“迁移路径”，从 0011 -> 0018 和 0011 -> 0020 用于同一个应用程序，即使它们不涉及相同的模型，那也不是很漂亮。我认为很可能：

1. 这些分支已经分离了 很长 时间，并且 2 种模式存在很大差异。这里有两种可能的情况：

   • 它们不会接触相同的模型（即它们不会“相交”）：您可以使用 --merge 乱序应用它们，但是很可能受影响的模型最好属于 2 个独立的应用程序。

   • 他们确实接触了相同的模型（我认为这可能是你的情况）：我必须同意@chrisdpratt这里，最好通过协调来完全避免这种情况/分开工作更好。 但是即使在这种情况下，特别是如果您只有架构迁移，并且您没有在两个分支中进行一些明显冲突的架构迁移（一个愚蠢的例子是添加一个同名的字段到在 2 个不同的迁移中使用相同的模型），您很可能可以使用 --merge 无序地应用迁移（或至少其中大部分）而不会出现问题。在许多情况下，模式迁移的顺序并不重要，即使它们影响相同的模型，但您确实需要手动检查。当出现问题时，您只需要更改它们的编号，没有自动解决方法。

2. 您为每个小的架构更改生成一个新的架构迁移：在开发过程中这没有什么问题，但是一旦功能完成（准备好合并）迁移应该被“压缩”成一个迁移（或至少更少）如果对某些逻辑分组有很多更改，或者如果您也有数据迁移，则迁移）。在已经进行最新迁移的开发环境中，这样做很简单

   • ./manage.py migrate myapp 0010 --fake
   • 删除迁移 0011-0018
   • ./manage.py schemamigration myapp schema_changes_for_new_feature_x --auto
   • ./manage.py migrate myapp 0011 --fake --delete-ghost-migrations

另一件事是，在具有不同迁移的两个分支之间合并后，您通常需要创建一个mergefix 架构迁移（具有空的向前/向后）方法，以在“冻结”模型中记录组合状态（否则South 会认为有未完成的架构更改）

Answer 2

我的回答是尽可能不提交迁移。如果迁移丢失，总是可以重新生成，所以假设除了我之外没有人需要运行我的分支，只是不要在最后提交迁移。

除此之外，我发现的最佳方法是将它们简单地视为合并冲突。当您合并回主干时，请检查您的迁移文件夹，并通过将您的迁移重命名为更高的编号来独立解决每个编号冲突。

当然，这两种方法都不理想，但在这方面没有太多选择。 South's own advice on the matter 不是在真空中发展。经常合并并与您正在合作的其他开发人员交流。

South 不能替代团队协调 [...] 确保您的团队知道谁在做什么，这样他们就不会编写同时影响数据库相同部分的迁移。

虽然该建议表面上听起来令人沮丧，但实际上，原则是正确的。不仅仅是关于迁移，让多个开发人员同时在系统的同一位上工作从来都不是一个好主意。将类似的任务分配给已经在该系统上工作的同一个开发人员，您不会有任何问题。