Проблемы с управлением версиями в мультиверсионном проекте

Question

Фон

У нас есть игра, работающая в трех разных регионах, так что это три разные версии веток релиза, которые извлекаются из одной главной ветки, скажем, branch_jp, branch_us, branch_tw (назовем их ветвями релиза) и мастера.

Обычно новые функции разрабатываются в основной ветке и объединяются в ветки выпуска. Но не все функции необходимы для каждой ветки выпуска - это определяется некоторыми операционными потребностями и т. Д. - поэтому требуется объединение с ними изменений основной ветки.

Проблема

Мы использовали Subversion для контроля версий, недавно мы решили перейти на Git.

Проблема заключается в том, что мы сделали в subversion, когда слияние кода заключалось в том, чтобы выбрать коммиты из master, необходимые для этой ветви, и объединить их, как показано ниже:

• commitA1
• commitA2
• commitB1
• commitB2
• commitA3

Если branch_jp нужна функция FeatureA, мы выбираем commitA & B и объединяем их в branch_jp, если branch_us просто нужна функция B, мы просто выбираем commitB.

Поскольку мы перешли на Git, предположим, что все функции разрабатываются в ветвях компонентов из master и объединяются в ветви релизов. Проблема в том, что мы не можем так поступить:

master → featurebranch → master → branch_jp/tw/us

или

master → featurebranch → branch_jp/tw/us

              ↓
            master

, поскольку ветвь функции извлекается из главного устройства, поэтому прежние функции, которые не были объединены в ветви выпуска, будут объединены таким образом.

Я знаю, что команда 'cherry-pick' может сделать то же самое, но мне интересно, есть ли еще какие-нибудь 'Git-y' способы справиться с ситуацией?

Кроме того, есть ли более распространенный / более приятный / элегантный рабочий процесс для обработки этой ситуации с кодами 'multi-release version'?

Answer 1

Я работал в местах, где есть эта проблема. Хотя с этим трудно справиться, я бы не рекомендовал рабочий процесс «вишни», который @Marina предложила в своем ответе. Причина, по которой я бы не рекомендовал это, заключается в том, что git cherry-pick разрывает связь между исходным коммитом и выбранным вишней, поэтому анализ истории Git также не сработает.

ИМХО у вас есть две лучшие альтернативы, каждая из которых имеет то преимущество, что они сохраняют идентичность фиксации и, таким образом, облегчают рассуждение о дереве исходных текстов.

1 (меньшее изменение по сравнению со статус-кво, но, возможно, немного утомительно).

Измените модель ветвления. Мастер (если он вообще существует) не должен содержать всех функций, а только core функций, которые есть во всех трех выпусках. Если предполагается, что функция присутствует только в одном выпуске, объедините ее только в одну ветку. Другими словами, ваш процесс выпуска должен включать одну из функций выбора , включая , а не удалить .

2 (большие изменения, больше усилий на начальном этапе, но облегчит дальнейшее развитие).

Переосмыслите свою архитектуру. Вместо трех поддерживаемых версий кода выпускайте только одну версию приложения и разнесите различия в конфигурационные файлы или плагины. Если вы сможете это сделать, вы, вероятно, увидите преимущества для качества своего кода, а не только простоту контроля версий.

Я бы настоятельно рекомендовал бы вариант 2, если это вообще возможно.

Answer 2

git cherry-pick (как вы знаете) является правильным и распространенным способом для этой ситуации.

Поскольку вам нужно выбрать разные функции для разных веток релиза, вам не следует использовать команду git merge, так как git merge объединит все изменения в ветки релиза.

А для вишневого выбора для разных веток релиза вы можете следовать следующим ситуациям:

• Применение изменений только для одной функции:

  Вам следует выбрать коммит из ветви функций. Например, применить изменения с featureA на branch_jp, you should cherry-pick the latest commit from featureA` ветку.

• Применение изменений для всех выпущенных функций:

  Вам просто нужно выбрать коммит из последнего слитого коммита. Например, примените изменения от функций A и B к branch_us, тогда вам просто нужно выбрать последнюю объединенную фиксацию в `branch_us.