使用带有多个代码分支的Django South的工作流程

问题描述

| 我对其他Django开发人员在使用多个代码分支进行开发时如何使用South管理其数据库迁移感到好奇。让我给出一个示例方案。 举例来说，您从主干开始开发。您从中继创建分支A。此时，ѭ0的最后一个迁移版本是0010。 然后，在创建迁移文件“ 2”的主干中为“ 0”创建迁移。同时，在分支A中，另一位开发人员为分支A中的相同“ 0”创建了一个不同的迁移文件：“ 4”。 分支A最终合并回主干。发生这种情况时，假设分支A的ѭ0last中的最后一个迁移版本是

0020

，而在主干中，最新版本是

0018

，它们都是不同的迁移。正如您所看到的，从版本ѭ8since开始，当分支是从trunk分支出来的时候，迁移文件的状态就混乱了。合并时它们都处于冲突状态。 根据South's的教程，处理这种情况的唯一方法是手动解决所有冲突。但是，如果冲突的数量很大，那么这并不是真正想要的解决方案。您通常如何处理这种情况，甚至一开始要避免这种情况？     

解决方法

        好吧，答案不是很简单。 TL; DR更新： 在大多数情况下，如果我们正在谈论Trunk <-> Branch工作流程，我可能会 从分支机构A的“压缩”新迁移到单个迁移（或最少可能） 合并所有中继更改/迁移到分支A。 重命名分支A迁移到0019，依此类推。 现在合并到树干。 更多详情 首先，合并多个具有相同前缀（即

0011

）的迁移（合并它们的不同分支）并不重要，只要它们不修改相同的模型即可。然后，您可以使用“ 10”选项简单地运行迁移，以应用无序迁移。 但是，如果对于同一应用程序，您从0011-> 0018和0011-> 0020有两个不同的\“迁移路径\”，即使它们不使用相同的模型，也不是很漂亮。我认为可能是： 这些分支已经分开很长时间了，这两种模式之间存在很大差异。这里有两种可能的情况： 它们不会碰到相同的模型（即，它们不会“相交”）：您可以不按顺序使用ѭ10来应用它们，但是受影响的模型很可能最好属于2个单独的模型应用程序代替。 它们确实使用相同的模型（我认为这可能是您的情况）：在这里我必须同意

@chrisdpratt

，最好通过更好地协调/分解工作来完全避免这种情况。但是即使在这种情况下，尤其是如果您仅进行模式迁移，并且在两个分支中也没有进行明显冲突的模式迁移（一个愚蠢的示例是在两次不同的迁移中将具有相同名称的字段添加到同一模型中），很可能您可以按10英镑的顺序无序应用迁移（或至少大多数迁移）而不会出现问题。在许多情况下，架构迁移的顺序并不重要，即使它们影响相同的模型，也需要手动进行检查。而且，如果遇到问题，您只需更改其编号，就不会自动解决。 您会为每个微小的模式更改生成一个新的模式迁移：开发过程中没有任何问题，但是一旦功能完成（准备合并），就应该将迁移“压缩”为单个迁移（或在迁移时）。如果逻辑分组有很多更改，或者您也有数据迁移，则迁移最少。在已经进行了最新迁移的开发环境中，只需执行以下操作即可 ./manage.py迁移myapp 0010 --fake 删除迁移0011-0018 ./manage.py schemamigration myapp schema_changes_for_new_feature_x --auto ./manage.py迁移myapp 0011 --fake --delete-ghost-migrations 另一件事是，在具有不同迁移的两个分支之间合并之后，您通常需要创建一个“ 14”模式迁移（具有空的前进/后退）方法，以在“冻结”模型中记录组合状态（否则

South

会认为存在显着的架构更改）     ,我的回答是尽可能不提交迁移。如果丢失，迁移总是可以重新生成，因此假设除了我之外没有人需要运行我的分支，只是直到最后才提交迁移。 除此之外，我发现的最佳方法是将它们简单地视为合并冲突。当您合并回中继时，请检查您的迁移文件夹，并通过将迁移重命名为更高的编号来独立解决每个编号冲突。 当然，这两种方法都不是理想的，但是在这方面没有很多选择。南方自己对此事的建议是不要在真空中发展。经常合并并与您正在使用的其他开发人员进行交流。   South不能替代团队协作，请确保您的团队知道谁在做什么，以便他们不要编写同时影响数据库相同部分的迁移。 尽管该建议听起来有些令人沮丧，但实际上，该原则是正确的。不仅仅是涉及迁移，让多个开发人员同时在同一系统上工作并不是一个好主意。将相同的任务分配给已经在该系统上工作的同一开发人员，您将不会有任何问题。