维持Django分叉的南迁移

Question

我正在研究一个非常复杂的Django项目(50多个模型),它有一些复杂的逻辑(许多不同的工作流程,视图,信号,API,后台任务等).我们称之为project-base.目前正在使用Django 1.6 + South迁移和其他一些第三方应用程序.

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

随着project-base未来的发展,我们希望这些功能也能进入project-fork(就像git-land中的rebase/merge).额外的更改project-fork将不会合并回来project-base.

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

1. 使用南合并在project-fork保持它最新的与最新变化project-base,为解释在这里.使用信号和任何其他必要手段来保持新逻辑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. 需要为fork进行模型更改的主题
2. 尽可能快地将这些更改应用于两个/所有分支以避免冲突
3. 在叉子上工作....
4. 合并不提供新迁移的fork

使用大叉子时,更改并不总是很明显和/或会再次发生变化:

1. 做一些正常的fork和开发工作,同时尽可能地与最新的master/develop分支保持同步
2. 在合并之前,丢弃fork中的所有模式迁移
3. 合并master/develop中的所有更改
4. 重新创建所有需要的架构更改
5. 合并开发/掌握