django - 在 Django fork 上维护南迁移

Question

我正在处理一个非常复杂的 Django 项目(50 多个模型)，其中包含一些复杂的逻辑(许多不同的工作流、 View 、信号、API、后台任务等)。让我们称之为 project-base .目前使用 Django 1.6 + South 迁移和很多其他 3rd 方应用程序。

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

如 project-base继续开发，我们希望这些功能也进入project-fork (很像 git-land 中的 rebase /合并)。 project-fork 中的额外变化不会合并回 project-base .

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

在 project-fork 中使用南合并使其与来自 project-base 的最新更改保持同步，如解释 here .使用信号和任何其他必要的手段来保持新逻辑来自 project-fork尽可能松散耦合以避免任何潜在的冲突。

请勿修改任何原始 project-base模型，而是在引用旧模型的不同应用程序中创建新模型(即使用 OneToOneField)。额外的逻辑可能会出现在旧的和/或新的应用程序中。

你的想法请在这里:)

我会选择选项 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

这显然不适用于所有情况，但根据我的经验，它适用于大多数情况。

陷阱:

对同一模型进行多次更改仍会中断

重复的更改可能会破坏事情

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

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

从一开始模型变化就很明显的小 fork :

讨论需要为前叉进行哪些模型更改

尽快将这些更改应用于两个/所有分支以避免冲突

在 fork 上工作....

合并没有新迁移的 fork

对于变化并不总是很明显和/或将再次发生变化的大 fork :

做正常的 fork 和开发工作，同时尽量保持最新的 master/develop 分支

在合并回来之前，扔掉所有架构 fork 中的迁移

合并来自 master/develop 的所有更改

重新创建所有需要的架构更改

合并开发/掌握