Какова хорошая стратегия ветвления при разработке сразу нескольких будущих выпусков?

Прошлое

Я разрабатываю программный проект, используя Subversion как scm. До сих пор разработка всегда происходила в trunk, поэтому проблемы возникали, когда требовалось исправление ошибок. Теперь мы хотим переосмыслить нашу стратегию ветвления, и требование следующее: мы хотим иметь возможность работать над несколькими будущими выпусками одновременно.

Задание

Это означает: предположим, что текущая версия, над которой мы работаем, - 1.0. Следующая запланированная версия - 2.0, следующая за ней - 3.0. Теперь, когда мы выпустили 1.0, мы хотим

  • поддерживать версию 1.0
  • разработать функции для 2.0
  • в то же время разрабатывать функции для 3.0

Конечно, исправления, которые были применены в 1.0, также необходимы и в двух других версиях. Кроме того, функции из версии 2.0 также должны быть в версии 3.0. Кроме того, вполне возможно, что планируется выпуск второстепенного выпуска, скажем, 1.1, который также включает новые функции и должен будет поддерживаться отдельно.

Возможное решение

Я придумал следующую стратегию ветвления:

  • Багажник будет заброшен
  • Для каждого нового запланированного выпуска создается ветка, основанная на ветке последнего выпуска.
  • Изменения распространяются «вверх» на шкале времени версии.

Позвольте мне уточнить это немного подробнее: в данном примере мы будем ветвить версию 1.0 от ствола. Кроме того, мы должны отделить версию 2.0 от версии 1.0 и версию 3.0 от версии 2.0. Когда в 1.0 вносятся изменения, они будут объединены с 2.0, а затем и с 3.0.

Визуализация описанной стратегии ветвления (прошу прощения за плохое качество краски)

Вопрос

Это действующая методология? Будет ли работать технически? Есть ли организационные ошибки? Есть ли лучшие практики? (Все, что может придумать Интернет, это: «Разрабатывать в основной ветке, поддерживать в ветке выпуска»). Мне особенно странно бросать багажник - это не так?


branch branching-strategy svn
person David    schedule 03.03.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Идея «разработки в trunk» исходит из того факта, что trunk - это ветка по умолчанию, которую вы можете захотеть проверить.
То есть: вы не знаете соглашения об именах для других ветвей, но вы, по крайней мере, знаете, что «основная "Ветвь называется" trunk ", поэтому, как новый разработчик, вы можете испытать соблазн проверить эту ветку, поэтому текущую разработку лучше всего проводить в той же ветке.

Ветви 1.0, 1.1 или 2.0 будут скорее использоваться для операций обслуживания после того, как эти выпуски будут выполнены.

Для параллельной разработки я бы порекомендовал другое соглашение об именах, например 1.1_dev, 2.0_dev, созданное на основе trunk (которое будет представлять текущую разработку 1.0).
Это может работать при условии, что эти ветки не слишком долговечны и что они не отклоняйтесь слишком сильно от trunk (из-за слияний, которые в противном случае усложнились бы).

person VonC    schedule 03.03.2011
comment
Звучит разумно. Но что будет после выпуска 1.0? В этом случае магистраль должна переключиться на 2.0, и 1.0 станет ветвью выпуска (то есть существует только для обслуживания). Как это переключение будет выглядеть технически? Переименуйте trunk в rb-1.0 и dev-2.0 в trunk? - person David; 03.03.2011
comment
@ Дэвид: переключение не задействовано: ствол остается стволом. Создается тег (неизменяемый '1.0') и создается ветка исправления ('1.0_fix'). Затем содержимое dev_2.0 должно стереть содержимое trunk, и ветвь dev_2.0 прекращает работу. - person VonC; 03.03.2011
comment
Я придерживаюсь методологии VonC, вся разработка происходит на транке. Каждый раз, когда вы будете готовы к готовности, вы помечаете транк, называете его 1.0 и отпускаете. Если в выпуске 1.0 есть какие-либо ошибки, вы разветвляете его (скажем, называете это 1.0_branch), проверяете исправление ошибок в нем, чтобы сделать выпуск, объединяйте это исправление ошибки в магистраль, чтобы поддерживать его в актуальном состоянии, и продолжайте работу над магистралью. Вы можете сделать так, чтобы каждый выпуск был веткой (эффективное создание версии 1.0 из ветки 1.0 не имеет никакого значения в этом контексте). - person omermuhammed; 03.03.2011
comment
@VonC: Спасибо за ответ. Тем не менее, я не уверен, как перевести содержимое dev_2.0, а затем необходимо стереть содержимое транка в терминологию svn. Я имею в виду, я думаю, что знаю, что вы собираетесь делать, но я не знаю, как это сделать технически. - person David; 04.03.2011
comment
@omermuhammed: Как бы вы решили проблему одновременной разработки нескольких будущих релизов? - person David; 04.03.2011
comment
@David: Я бы пошел простым путем и просто сделал зеркальную копию dev_2.0 содержимого (только файлы и каталоги, а не .svn matadata) в trunk рабочем дереве перед добавлением / удалением / обновлением этих файлов в trunk. - person VonC; 04.03.2011
comment
Это возможно, в магистрали идентифицировать ревизию как стабильную точку для запуска нескольких выпусков. Затем создайте столько веток, сколько вам нужно, по одной для каждого выпуска. Держите самый важный выпуск на багажнике. И когда вы сочтете нужным (обычно после выпуска из этой ветки), выполните слияние из ветвей выпуска обратно в ствол. - person omermuhammed; 04.03.2011