在Django叉上维持南迁移

Question

我正在处理一个相当复杂的Django项目(50+模型)，它有一些复杂的逻辑(许多不同的工作流、视图、信号、API、后台任务等等)。让我们称其为project-base。目前使用Django 1.6 +南方迁移和相当多的其他第三方应用。

现在，其中一个要求是创建这个项目的分支，它将在这里和那里添加一些字段/模型，并在此基础上添加一些额外的逻辑。让我们称其为project-fork。大部分额外的工作将在现有的模式之上，但也会有一些新的。

随着project-base的不断开发，我们希望这些特性也能进入project-fork (就像git-land中的重基/合并)。project-fork中的额外更改不会合并回project-base中。

实现这一目标的最佳方法是什么？以下是我的一些想法：

1. 使用project-fork中的South使其与project-base的最新变化保持一致，正如here解释的那样。使用信号和任何其他方法，必须尽可能地将新逻辑与project-fork保持松散耦合，以避免任何潜在的冲突。
2. 不要修改任何原始的project-base模型，而是在引用旧模型的不同应用程序中创建新模型(即使用OneToOneField)。额外的逻辑可能最终会出现在旧的和/或新的应用程序中。
3. 你在这里的想法是:)

我会选择选项1，因为总体上它似乎不那么复杂，但可能暴露出更大的风险。以下是我对此的看法：

project-base上的迁移

• 0001_project_base_one
• 0002_project_base_two
• 0003_project_base_three

project-fork上的迁移

• 0001_project_base_one
• 0002_project_fork_one

合并之后，迁移将如下所示：

• 0001_project_base_one
• 0002_project_base_two
• 0002_project_fork_one
• 0003_project_base_three
• 0004_project_fork_merge_noop (添加以合并来自两个项目的更改)

使用这种方法有什么缺陷吗？有更好的办法吗？

谢谢您抽时间见我。

Answer 1

南方正式工作流程：

南方的官方建议是尝试使用--merge标志：http://south.readthedocs.org/en/latest/tutorial/part5.html#team-workflow

这显然不会在所有情况下都起作用，但从我的经验来看，它在大多数情况下都是有效的。

陷阱：

• 对同一个模型的多个更改仍然会中断。
• 重复的更改会破坏事物。

“更好”的方法通常是避免同时更改相同的模型，最简单的方法是尽可能地减少错误窗口。

在这些情况下，我的个人工作流程：

带有小叉子的，从一开始就明显地改变了模型：

1. 需要对叉子进行哪些模型更改？
2. 尽快将这些更改应用于两个/所有分支，以避免冲突。
3. 做叉子..。
4. 合并不允许新迁移的分叉

带有大叉的，其中的更改并不总是明显的和/或将再次更改：

1. 做好正常的分叉和开发工作，同时尽可能地与最新的硕士/开发部门保持联系。
2. 在合并之前，将所有的schemamigrations丢弃在分叉中。
3. 合并主/开发中的所有更改
4. 重新创建所有需要的架构更改。
5. 合并为开发/掌握