我很好奇其他Django开发人员在开发多个代码分支时如何管理他们与South的数据库迁移。让我举一个示例场景。
例如，假设您使用主干线开始开发。您从主干创建分支A.此时，app_1的上一个迁移版本为0010。
然后，您在主干中为app_1创建一个迁移文件0011_add_name_column的迁移。同时，在分支A中，另一个开发人员为分支A：app_1中的同一0011_increase_value_column_size创建不同的迁移文件。
分支A最终被合并回主干。发生这种情况时，请说分支A中的app_1中的上一个迁移版本为0020，而后备版中的最后一个版本为0018，并且它们都是不同的迁移。正如您所看到的，迁移文件的状态从版本0011开始搞乱，当分支从主干分叉时...并且它们在合并时都会发生冲突。
根据South's tutorial，处理此案例的唯一方法是手动解决所有冲突。但是，如果冲突的数量很大，这并不是一个理想的解决方案。你通常如何处理这种情况，甚至首先要避免这种情况？
答案 0 :(得分：18)
嗯，答案不是很简单。
TL; DR更新： 在大多数情况下，如果我们正在谈论Trunk＆lt; - ＆gt;分支工作流程我可能会
更多细节
首先，如果您有多个具有相同前缀（即0011）的迁移与合并不同的分支无关紧要，只要它们不会对其进行修改楷模。然后，您只需使用--merge选项运行迁移即可应用无序迁移。
但是如果你有两个不同的“迁移路径”来自0011 - ＆gt; 0018和0011 - ＆gt; 0020对于同一个应用程序，即使他们没有触摸相同的型号，也不是很漂亮。我认为这可能是：
这些分支已经分开了很长时间，并且在2个模式中存在很大的差异。这里有两种可能的情况：
他们没有碰到相同的模型（即他们没有“相交”）：你可以只使用--merge，然后来应用它们。可能受影响的模型应该更好地属于2个独立的应用程序。
他们做触摸相同的模型（我认为这可能是你的情况）：我必须同意@chrisdpratt这里，最好完全避免这种情况更好地协调/分配工作。 但即使在这种情况下，特别是如果你只有模式迁移，并且你没有在两个分支中做一些明显冲突的模式迁移（一个愚蠢的例子是添加一个具有相同名称的字段）在2个不同的迁移中使用相同的模型），很可能您只需将--merge中的迁移（或至少大部分）无序应用而没有问题。在许多情况下，即使模式迁移影响同一模型，模式迁移的顺序也无关紧要，但您需要手动检查。如果这是一个问题，你只需要改变它们的编号，就没有自动解决它。
为每个小模式更改生成新的模式迁移：在开发期间，这没有任何问题，但是一旦功能完成（准备合并），迁移应该“压缩”为单个迁移（或如果某些逻辑分组发生了很多更改，或者您还有数据迁移，则至少迁移次数减少。在已经进行最新迁移的开发环境中，只需执行
即可另一件事是，在两个具有不同迁移的分支之间合并之后，您通常需要创建mergefix模式迁移（使用空的前向/后向）方法，以在“冻结”中记录组合状态“模型（否则South会认为存在未完成的架构更改）
答案 1 :(得分：10)
我的答案是尽可能不提交迁移。迁移总是可以在丢失的情况下重新生成，因此假设除了我之外没有人需要运行我的分支，只是不要在最后提交迁移。
除此之外，我发现的最好方法是简单地将它们视为合并冲突。当您合并回主干时，请检查您的迁移文件夹，并通过将迁移重命名为更高的数字来单独解决每个编号冲突。
当然，这两种方法都不理想，但在这方面并没有很多选择。 South's own advice on the matter不是在真空中发展。经常合并并与您正在合作的其他开发人员进行沟通。
南方不能替代团队协调[...]确保您的团队知道谁在做什么，因此他们不会同时编写影响数据库相同部分的迁移。
虽然这个建议在表面上可能听起来令人沮丧，但事实上，这个原则是正确的。不仅仅是关于迁移，让多个开发人员同时在同一个系统上工作也绝不是一个好主意。将类似的任务分配给已经在该系统上工作的同一个开发人员，您将不会遇到任何问题。