使用Django South与多个代码分支的工作流程 [英] Workflow for Using Django South with Multiple Code Branches

问题描述

对于其他Django开发人员在使用多个代码分支进行开发时，如何管理与South的数据库迁移，我很好奇。让我来一个示例场景。

举个例子，你用你的主干开始你的开发。您从树干创建分支机构A.此时， app_1 的最后一个迁移版本为0010。

然后，为<$ c创建迁移$ c> app_1 在创建迁移文件的中继 0011_add_name_column 中。同时，在分支A中，另一个开发人员在分支A中为相同的 app_1 创建不同的迁移文件： 0011_increase_value_column_size 。 / p>

分支A最终被合并回到中继线。发生这种情况时，说分行A中的 app_1 中的上一个迁移版本是 0020 ，而在中继中最后一个版本是 0018 ，它们都是不同的迁移。如您所见，迁移文件的状态自版本 0011 被破坏后，当分支从中继线分叉时，并且它们在合并时都处于冲突状态。

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

解决方案

那么这个答案是不太简单。

TL; DR更新：
在大多数情况下，如果我们在说一个中继线工作流程我可能会

1. 压缩从分支机构A的新迁移到单一迁移（或最不可能的）


2. 将所有中继线更改/迁移合并到分支机构A.


3. 将分支机构A重命名为0019，等等。


4. 现在合并到中继线。

更多细节

如果您有合并不同分支的多个具有相同前缀的迁移（即 0011 ），只要不会修改相同的型号。然后，您可以使用 - merge 选项运行迁移，以应用无序迁移。

但是如果你对于相同的应用程序，对于相同的应用程序，它们具有从0011 - > 0018和0011 - > 0020两个不同的迁移路径，即使它们不接触相同的模型，这不是很漂亮。我认为这可能是：

1. 这些分支已经分开了一段很长的 时间，在两个模式中存在很大差距。这里有两种可能的情况：

   
   
   
   
   

   • 他们没有触摸相同的模型（即它们不相交） ：您可以使用 - 合并，然而按顺序应用它们，因此受影响的模型很可能应该更好地属于2个单独的应用程序。

   
   

   • 他们做触摸相同的模型（我认为这可能是你的情况）：我必须同意 @chrisdpratt 这里，最好通过更好地协调/分解工作来避免这种情况。 但是即使在这种情况下，特别是如果您只有模式迁移，并且您不会在两个分支中做一些明显冲突的模式迁移（愚蠢的示例将添加一个具有相同名称的字段相同的模型在2个不同的迁移），很可能您只需应用迁移（或至少大多数），不合格的 - 合并无问题。在许多情况下，即使它们影响相同的模型，模式迁移的顺序也不会重要，但您需要手动检查。而当这是一个问题时，您只需要更改编号，就不会有自动的方式。

   
   



2. 您可以为每个小型模式更改生成新的模式迁移：开发过程中没有任何错误，但一旦功能完成（准备合并），迁移应该被压缩为单个迁移（或至少少于迁移，如果有一些逻辑分组有很多变化，或者如果您还有数据迁移）。在已经在最新迁移的开发环境中，只需执行

   
   
   
   
   
   • ./ manage.py migrate myapp 0010 - fake
   
   
   • 删除迁移0011-0018
   
   
   • ./ manage.py schemamigration myapp schema_changes_for_new_feature_x --auto
   
   
   • ./管理.py迁移myapp 0011 - fake --delete-ghost-migrations
   
   

另一件事是，在两个不同迁移的分支合并之后，您通常需要创建一个 mergefix 模式迁移（具有空的向前/向后）方法来记录在冻结模式中的组合状态（否则 South 将认为有未完成的模式更改）

I'm curious as to how other Django devs manage their database migrations with South when developing with multiple code branches. Let me give a sample scenario.

Say for example you start you development with your main trunk. You create Branch A from the trunk. At this point, the last migration version for app_1 is 0010.

Then you create a migration for app_1 in the trunk that creates a migration file 0011_add_name_column. Meanwhile, in branch A, another developer creates a different migration file for the same app_1 in branch A: 0011_increase_value_column_size.

Branch A eventually gets merged back to trunk. When this happens, say last migration version in app_1 in Branch A is 0020 and in the trunk the last version is 0018, and they're all different migrations. As you can see, the state of the migration files are messed up since version 0011, when the branch was forked from trunk.. and they're all in conflicts upon merging.

According to South's tutorial, the only way to handle this case is to manually resolve all the conflicts. However, this is not really a desired solution if the amount of conflicts are significant. How do you typically handle this situation, or even to avoid it in the first place?

解决方案

Well, the answer to this is not very straightforward.

TL;DR update: In most cases, if we are talking a Trunk <-> Branch workflow I would probably

1. "Compress" new migrations from Branch A into a single migration (or least possible)
2. Merge all trunk changes/migrations to Branch A.
3. Rename Branch A migrations to 0019 and so on.
4. Now merge to trunk.

More detail

First of all, it doesn't matter if you have multiple migrations with same prefix (i.e. 0011) from merging different branches, as long as they don't modify the same models. Then you can simply run migrate with the --merge option to apply out of order migrations.

But if you have two different "migration paths" from 0011 -> 0018 and 0011 -> 0020 for the same app, even if they don't touch the same models, that's not very pretty. I think it's likely that either:

1. Those branches have been separated for a very long time and there's a large disparity in the 2 schemas. There are 2 possible situations here:

   • They don't touch the same models (i.e they don't "intersect"): You can just apply them out of order with --merge, however it's very likely the affected models should better belong to 2 separate apps instead.

   • They do touch the same models (which I assume it's probably your case): I have to concur with @chrisdpratt here, that it's best to avoid this situation altogether by coordinating/splitting up work better. But even in this case, especially if you have only schema migrations, and you don't do some obviously conflicting schema migrations in the two branches (a stupid example would be adding a field with the same name to same model in 2 different migrations), it's pretty likely that you can just apply the migrations (or at least most of them) out of order with --merge without problems. In many cases the order of the schema migrations won't matter even if they affect the same model, you do need to check this manually however. And when it's an issue, you'll just have to change their numbering, there's no automatic way around it.

2. You generate a new schema migration for every little schema change: There's nothing wrong with this during development, but once the feature is complete (ready for merging) the migrations should be "compressed" into a single migration (or at least less migrations if there are a lot of changes with some logical grouping, or if you also have data migrations). On dev environment which is already on latest migration, it's simple to just do

   • ./manage.py migrate myapp 0010 --fake
   • delete migrations 0011-0018
   • ./manage.py schemamigration myapp schema_changes_for_new_feature_x --auto
   • ./manage.py migrate myapp 0011 --fake --delete-ghost-migrations

Another thing is, that after merging between two branches with different migrations, you'll often need to create a mergefix schema migration (with empty forwards/backwards) methods, to record the combined state in the "frozen" models (otherwise South will think there are outstanding schema changes)

这篇关于使用Django South与多个代码分支的工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！