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

Posted 2023-02-24

【中文标题】将 Django South 与多个代码分支一起使用的工作流程

【英文标题】：Workflow for Using Django South with Multiple Code Branches

【发布时间】：2011-09-14 04:08:10

【问题描述】：

我很好奇其他 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，处理这种情况的唯一方法是手动解决所有冲突。但是，如果冲突的数量很大，这并不是真正需要的解决方案。您通常如何处理这种情况，甚至一开始就避免这种情况？

【参考方案1】：

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

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

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

更多细节

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

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

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

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

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

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

./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 会认为有未完成的架构更改）

【参考方案2】：

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

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

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

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

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

【讨论】：

并非总是可以生成它们，我必须在之前编写手动迁移，在这种情况下，它们需要提交到源代码控制

我在 South 进行了 很多 次迁移。我从来不需要手动编写 schema 迁移。现在，数据迁移是另一回事，显然您不想删除任何自定义数据迁移。但是，如果您在 inside 架构迁移中进行数据迁移，那么您做错了。否则，我会非常仔细研究为什么您需要自定义模式迁移，因为在两年多的时间里，我从未遇到过实际需要使用 Django 和 South 迁移的单一场景。

我不会说这是常见的情况，但在多年使用 Django 和 South 的过程中，我不得不这样做几次。每次都是由于团队中某人的错误，不同分支中的两次迁移导致的冲突，或者在开发和生产中使用不同的数据库技术的问题。当它发生时肯定总是一件坏事，但它已经发生了，我很高兴那些迁移在它发生时处于源代码控制中。