Поддержание южных миграций на вилках Django

Я работаю над довольно сложным проектом Django (более 50 моделей) с некоторой сложной логикой (множество различных рабочих процессов, представлений, сигналов, API-интерфейсов, фоновых задач и т.д.). Позвольте называть это project-base. В настоящее время используется миграция Django 1.6 + South и немало других сторонних приложений.

Теперь одно из требований - создать вилку этого проекта, которая добавит некоторые поля/модели здесь и там, а также дополнительную дополнительную логику. Позвольте называть это project-fork. Большая часть дополнительной работы будет поверх существующих моделей, но также будет несколько новых.

По мере того, как project-base продолжает развиваться, мы хотим, чтобы эти функции также попадали в project-fork (так же, как rebase/merge в git -land). Дополнительные изменения в project-fork не будут объединены обратно в project-base.

Что может быть наилучшим возможным способом для этого? Вот некоторые из моих идей:

Использование юга объединяется в project-fork, чтобы поддерживать его в актуальном состоянии с последними изменениями от project-base, как описано здесь. Используйте сигналы и любые другие средства, необходимые для того, чтобы сохранить новую логику от project-fork настолько свободно, насколько это возможно, чтобы избежать любых потенциальных конфликтов.
Не изменяйте ANY из исходных моделей 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 (добавляется для слияния изменений в обоих проектах)

Есть ли подводные камни, использующие этот подход? Есть ли лучший способ?

Спасибо за ваше время.

Ответ 1

Официальный южный рабочий процесс:

Официальная рекомендация Юга - попробовать флаг --merge: http://south.readthedocs.org/en/latest/tutorial/part5.html#team-workflow

Это, очевидно, не будет работать во всех случаях, по моему опыту он работает в большинстве случаев.

Ловушки:

Несколько изменений в одной и той же модели могут по-прежнему прерываться
Повторяющиеся изменения могут сломать вещи.

"Лучше", как правило, избегать одновременных изменений в тех же моделях, самый простой способ сделать это - максимально уменьшить окно ошибки.

Мои личные рабочие процессы в этих случаях:

С маленькими вилками, где изменения модели очевидны с самого начала:

Discus, какие изменения модели необходимо будет сделать для fork
Примените эти изменения к обоим/всем ветвям как можно быстрее, чтобы избежать конфликтов.
Работа над вилкой....
Объединить вилку, которая не дает никаких новых перемещений.

С большими вилками, где изменения не всегда очевидны и/или будут меняться снова:

Сделайте обычную вилку и материал для разработки, пытаясь максимально обновиться с последней ветвью мастера/разработки
Перед слиянием обратно отбросьте все схемы миграции в fork
Слить все изменения с мастера/разработки
Восстановить все необходимые изменения схемы.
Объединить для разработки/мастеров