Основная причина, по которой вы переходите , заключается в изоляции усилий по разработке.
Так что это действительно зависит от того, что вы считаете наиболее важным изолировать:
- усилие по продвижению для данного выпуска (которое изолирует коммиты на этом этапе продвижения: тестирование, интеграция или прод / исправления)
- выпуск релиза (который будет включать в себя юнит-тестирование, интеграцию, этапы производства все один за другим)
Code-Promotion позволяет параллельно продвигать усилия для каждого выпуска (вы развиваете n + 2, тестируя n + 1 и поддерживая n).
В то время как Branch per Release допускает более простой и последовательный цикл разработки, где вы в основном тестируете и поддерживаете n при разработке n + 1.
Какой бы ни была выбранная стратегия, вам нужно обратиться к шагу синхронизации между n и n + 1 (что и когда вы объединяете эволюции от n до n + 1?):
- С Code-Promotion вы можете объединяться на разных этапах
- При использовании Branch per Release вы, как правило, объединяетесь только из одного выпуска с текущим состоянием разработки для другого выпуска.
Таким образом, в основном стратегия продвижения кода означает больше веток, больше слияний и больше точности в истории, которые хранятся и изолируются в этих ветвях.
Но это также означает больше среды для настройки и управления.
Branch Per Release более прост (при условии, что вы знаете, что то, над чем вы работаете, действительно станет частью следующего выпуска).