Почему слияние веток функций с ветками релиза — плохая идея?

Мы приняли модель ветвления, предложенную Винсентом Дриссеном, и почти все, как он описал в своей статье.

Только когда дело доходит до обработки веток релиза, мы немного отклоняемся.

Винсент предлагает разрабатывать функции в ответвлениях от разработчика. Когда принимается решение, какие функции войдут в следующий выпуск, они снова объединяются в разработчике, и из него создается ветка выпуска.

После этого функциональную ветку следует использовать только для тестирования и исправления ошибок. Когда релиз развертывается, ветвь релиза снова объединяется с ветвями разработчика и мастера.

Вместо этого мы объединяем функции непосредственно в ветку релиза:

Я чувствую, что это не так, как следует делать, и я пытаюсь думать о случаях, когда это может действительно усложнить ситуацию.

Я могу думать о следующем:

Допустим, новая Функция c строится на основе Функции a, которая уже объединена в ветку выпуска. Сначала мне нужно объединить ветвь выпуска обратно в ветвь разработчика, чтобы иметь возможность создать новую ветвь Feature c от разработчика.

Существуют ли другие случаи, когда эта модель ветвления может усложнить ситуацию?


git branching-and-merging
person Zounadire    schedule 15.07.2013    source источник
comment
@downvoters, пожалуйста, оставьте комментарий, чтобы улучшить качество моего вопроса :) Название вводит в заблуждение?   -  person Zounadire    schedule 15.07.2013
comment
Честно говоря, отвечая, как эта модель может все усложнить? похоже на ответ Что может пойти не так при написании кода на Java? Эта модель более или менее хороша, если вы не ослабите ее предположения о восходящих и нисходящих коммитах и ​​базах слияния. Но опять же, это верно для каждой модели ветвления.   -  person Christopher    schedule 16.07.2013

Ответы (1)


arrow_upward
8
arrow_downward

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

Представьте, что вы разрабатываете функцию A, которая сразу же появится в следующем выпуске. Теперь есть еще одна команда разработчиков, которая будет работать над функцией B, которая сильно зависит от функции A, но она должна быть выпущена только после пары спринтов. Итак, очевидно, мы будем отделять функцию B от функции A.

Теперь, когда вы нашли ошибку в функции A, ваш релиз для функции A быстро приближается, у вас есть два варианта: исправление/взлом или надлежащий рефакторинг кода и исправление.

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

Счастливая новость заключается в том, что мы можем пойти на обоих.

С вашей стратегией (насколько я понимаю) ваша ветвь выпуска будет получать все исправления и исправления (содержит 5+ коммитов), поскольку вы не можете зафиксировать что-либо подобное для функции A (если вы строги к политикам). Подумайте, сколько таких исправлений будет в выпуске, если у вас будет более 10 функций одновременно.

Но со стратегией Винсента Дриссена всегда есть ветка разработки в качестве тайника между вашей функцией и выпуском, поэтому для таких исправлений вы можете объединиться обратно в ветку разработки, а затем разветвиться оттуда для исправлений, а затем снова объединиться в разработку, а затем в выпускать. И у вас есть преимущество в том, что нигде в вашей функциональной ветке нет хаков/хотфиксов. Дальнейшие функции, основанные на этой функции, могут продолжаться параллельно. А можно отказаться от веток хотфиксов или удалить из истории. Это только одна точка зрения, и, возможно, в этом случае вы сможете отстоять свою стратегию. Я открыт для дальнейших обсуждений и исправлений в моем ответе :)

А вот довольно неприятная картинка, изображающая то, что я передаю. Схема ветвления Git

person egghese    schedule 15.07.2013