将 Django South 与多个代码分支结合使用的工作流程
我很好奇其他 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 的教程，处理这种情况的唯一方法是手动解决所有冲突。然而，如果冲突数量很大，这并不是真正理想的解决方案。您通常如何处理这种情况，甚至从一开始就避免这种情况？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
嗯，这个问题的答案并不是很简单。
TL；DR 更新：
在大多数情况下，如果我们谈论的是 Trunk <->分支工作流程我可能会将
更多详细信息
首先，如果您通过合并不同分支进行具有相同前缀（即
0011）的多个迁移并不重要，只要 他们不会修改相同的模型。然后，您只需使用--merge选项运行 migrate 即可应用无序迁移。但如果你从0011开始有两条不同的“迁移路径”-> 0018 和 0011 --> 0020 对于同一个应用程序，即使它们不触及相同的模型，那也不是很漂亮。我认为很可能是：
这些分支已经分离了很长时间，并且这两个模式存在很大差异。这里有两种可能的情况：
它们不接触相同的模型（即它们不“相交”）：您可以使用
--merge不按顺序应用它们，但是< /strong> 受影响的模型很可能最好属于 2 个独立的应用程序。他们确实接触相同的模型（我认为这可能是你的情况）：我必须同意
@chrisdpratt这里，最好避免这种情况完全可以通过更好地协调/分解工作来解决。 但是即使在这种情况下，特别是如果您只有架构迁移，并且您没有在两个分支中执行一些明显冲突的架构迁移（一个愚蠢的示例是将具有相同名称的字段添加到相同的模型在 2 个不同的迁移中），您很可能可以使用--merge无序地应用迁移（或至少是大多数迁移）而不会出现问题。在许多情况下，架构迁移的顺序并不重要，即使它们影响同一模型，但您确实需要手动检查这一点。当出现问题时，您只需更改其编号即可，没有自动解决方法。为每个小的模式更改生成一个新的模式迁移：在开发过程中这没有任何问题，但是一旦功能完成（准备合并），迁移应该“压缩”为单个迁移（或至少更少）如果某些逻辑分组发生大量更改，或者您也有数据迁移）。在已经进行最新迁移的开发环境中，操作起来很简单
另一件事是，之后在具有不同迁移的两个分支之间进行合并时，您通常需要创建一个
mergefix架构迁移（具有空的向前/向后）方法，以记录“冻结”模型中的组合状态（否则South会认为存在显着的架构更改）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
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--mergeoption 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:
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
@chrisdpratthere, 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--mergewithout 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.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
Another thing is, that after merging between two branches with different migrations, you'll often need to create a
mergefixschema migration (with empty forwards/backwards) methods, to record the combined state in the "frozen" models (otherwiseSouthwill think there are outstanding schema changes)我的答案是尽可能不进行迁移。如果丢失，迁移总是可以重新生成，因此假设除了我之外没有人需要运行我的分支，直到最后才提交迁移。
除此之外，我发现的最好方法就是简单地将它们视为合并冲突。当您合并回主干时，请检查您的迁移文件夹，并通过将迁移重命名为更高的编号来独立解决每个编号冲突。
诚然，这两种方法都不是理想的，但在这方面没有太多选择。 South 自己对此事的建议是不要在真空中进行开发。经常合并并与与您一起工作的其他开发人员进行沟通。
虽然这个建议表面上听起来可能令人沮丧，但实际上，原则是正确的。不仅仅是涉及迁移，让多个开发人员同时在系统的同一部分上工作从来都不是一个好主意。将类似的任务分配给已经在该系统上工作的同一开发人员，您不会遇到任何问题。
My answer has been not committing migrations when possible. Migrations can always be regenerated if lost, so assuming no one but me needs to run my branch, just don't commit your migrations until the very end.
Short of that, the best method I've found is to simply treat them as merge conflicts. When you merge back into trunk, check your migration folder(s), and independently resolve each numbering conflict by renaming your migrations to higher numbers.
Granted, neither method is ideal, but there's not a whole lot of options on this front. South's own advice on the matter is to not develop in a vacuum. Merge often and communicate with the other developers you're working with.
While that advice may sound frustrating on the surface, in reality, the principle is right. More than just concerning migrations, it's never really a good idea to have multiple developers working on the same bit of the system at the same time. Assign similar tasks to the same developer who is already working on that piece of the system, and you won't have any problems.