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

Question

我很好奇其他Django开发人员在开发多个代码分支时如何管理他们与South的数据库迁移.让我举一个示例场景.

比如说你用主干开始开发.您从主干创建分支A. 此时,上次迁移的版本为app_10010.

然后,app_1在创建迁移文件的主干中创建迁移0011_add_name_column.同时,在分支A中,另一个开发人员app_1在分支A:中创建相同的迁移文件0011_increase_value_column_size.

分支A最终合并回主干.发生这种情况时,请说app_1分支A中的最后一个迁移版本是0020最后一个版本的主干0018,并且它们都是不同的迁移.正如您所看到的,迁移文件的状态从版本开始变得混乱0011,当分支从主干分叉时......并且它们在合并时都会发生冲突.

根据South的教程,处理这种情况的唯一方法是手动解决所有冲突.但是,如果冲突的数量很大,这并不是一个理想的解决方案.你通常如何处理这种情况,甚至首先要避免这种情况？

Answer 1

嗯,答案不是很简单.

TL; DR更新:在大多数情况下,如果我们正在谈论Trunk < - >分支工作流程,我可能会

1. 将分支A中的新迁移"压缩"为单个迁移(或尽可能少)
2. 将所有主干更改/迁移合并到分支A.
3. 重命名分支A迁移到0019,依此类推.
4. 现在合并到主干.

更多详情

首先0011,只要不修改相同的模型,只要合并不同的分支有多个具有相同前缀(即)的迁移并不重要.然后,您可以使用--merge选项来运行迁移,以应用无序迁移.

但是如果你有相同的应用程序从0011 - > 0018和0011 - > 0020有两个不同的"迁移路径",即使他们没有触及相同的模型,这也不是很漂亮.我认为这可能是:

1. 那些分支已经分离了很长时间,并且在两个模式中存在很大的差异.这里有两种可能的情况:

   • 它们不会触及相同的模型(即它们不会"交叉"):您可以将它们无序应用--merge,但受影响的模型很可能最好属于2个独立的应用程序.

   • 他们确实触摸了相同的模型(我认为这可能是你的情况):我必须同意@chrisdpratt这一点,最好通过更好地协调/分割工作来完全避免这种情况.但即使在这种情况下,特别是如果你只有模式迁移,并且你没有在两个分支中做一些明显冲突的模式迁移(一个愚蠢的例子是在两个不同的迁移中向同一模型添加一个具有相同名称的字段) ,您很可能只是--merge无故障地应用迁移(或至少大部分).在许多情况下,即使模式迁移影响同一模型,模式迁移的顺序也无关紧要,但您需要手动检查.当这是一个问题时,你只需要改变它们的编号,没有自动的方法.

2. 您为每个小模式更改生成新的模式迁移:在开发过程中这没有任何问题,但是一旦功能完成(准备合并),迁移应该"压缩"为单个迁移(或者至少迁移更少)对某些逻辑分组进行了大量更改,或者您还有数据迁移).在已经进行最新迁移的开发环境中,这很简单

   • ./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

另一件事是,在两个具有不同迁移的分支之间合并之后,您通常需要创建一个mergefix模式迁移(使用空的前向/后向)方法,以在"冻结"模型中记录组合状态(否则South会认为存在出色的架构变化)

Answer 2

我的答案是在可能的情况下不进行迁移.迁移总是可以在丢失的情况下重新生成,因此假设除了我之外没有人需要运行我的分支,只是不要在最后提交迁移.

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

当然,这两种方法都不理想,但在这方面并没有很多选择.南方对此事的建议是不要在真空中发展.经常合并并与您正在使用的其他开发人员进行沟通.

南方不能替代团队协调[...]确保您的团队知道谁在做什么,因此他们不会同时编写影响数据库相同部分的迁移.

虽然这个建议在表面上可能听起来令人沮丧,但事实上,这个原则是正确的.不仅仅是关于迁移,让多个开发人员同时在同一个系统上工作也绝不是一个好主意.将类似的任务分配给已经在该系统上工作的同一个开发人员,您将不会遇到任何问题.