我很好奇其他 Django 开发人员在使用多个代码分支进行开发时如何使用 South 管理数据库迁移。让我举一个示例场景。
举例来说，您从主干开始开发。您从主干创建分支 A。此时，最后一个迁移版本为app_1是0010。
然后您为app_1在创建迁移文件的主干中0011_add_name_column。同时，在分支 A 中，另一位开发人员为同一分支创建了不同的迁移文件app_1在分支A：0011_increase_value_column_size.
分支 A 最终合并回主干。发生这种情况时，请说最后一个迁移版本app_1在分支 A 中是0020在后备箱中，最后一个版本是0018，而且它们都是不同的迁移。如您所见，自版本以来迁移文件的状态变得混乱0011，当分支从主干分叉时......并且它们在合并时都存在冲突。
根据南的教程 http://south.aeracode.org/docs/tutorial/part5.html，处理这种情况的唯一方法是手动解决所有冲突。然而，如果冲突数量很大，这并不是真正理想的解决方案。您通常如何处理这种情况，甚至如何从一开始就避免这种情况？
嗯，这个问题的答案并不是很简单。
TL;DR 更新：
在大多数情况下，如果我们谈论的是主干 分支工作流程，我可能会
- 将分支 A 中的新迁移“压缩”为单个迁移（或最少可能）
- 将所有主干更改/迁移合并到分支 A。
- 将分支 A 迁移重命名为 0019，依此类推。
- 现在合并到主干。
更多详情
首先，如果您有多个具有相同前缀的迁移（即0011）通过合并不同的分支，只要他们不修改相同的模型。然后你可以简单地运行 migrate--merge应用无序迁移的选项。
但是，如果同一个应用程序有从 0011 -> 0018 和 0011 -> 0020 两个不同的“迁移路径”，即使它们不触及相同的模型，这也不是很漂亮。我认为很可能是：
-
这些分支已被分开一段时间很长时间，并且这两种模式存在很大差异。这里有2种可能的情况：
它们不接触相同的模型（即它们不“相交”）：您可以不按顺序应用它们--merge, however受影响的模型很可能最好属于 2 个独立的应用程序。
They do触摸相同的模型（我认为这可能是你的情况）：我必须同意@chrisdpratt在这里，最好通过更好地协调/分解工作来完全避免这种情况。But即使在这种情况下，特别是如果您只有架构迁移，并且您没有在两个分支中进行一些明显冲突的架构迁移（一个愚蠢的示例是在两个不同的迁移中将同名字段添加到同一模型），您很可能可以无序地应用迁移（或至少是大多数迁移）--merge没有什么问题。在许多情况下，架构迁移的顺序并不重要，即使它们影响相同的模型，但您确实需要手动检查这一点。当出现问题时，您只需更改它们的编号即可，没有自动解决方法。
-
您为每个小的模式更改生成一个新的模式迁移：在开发过程中这没有任何问题，但是一旦功能完成（准备合并），迁移应该“压缩”为单个迁移（或者至少更少的迁移，如果有）是一些逻辑分组的很多变化，或者如果您也有数据迁移）。在已经进行最新迁移的开发环境中，执行起来很简单
- ./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会认为存在显着的架构更改）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
