Здравствуйте, m2user, Вы писали:

m> Z>> Жизненный цикл таски — стартуем ветку от release, вливаем в develop, тестируем, после апрува QA эту же ветку таски вливаем в бранч.
m> ·>Плохо. Будут мучения с резолвингом конфликтов.
m> ·>Мерж таск-ветки в релиз и в девелоп происходят в разное время. Более менее работоспособно только для маленьких проектов с парой независимых тасков. На большом проекте у тебя будет много таск-веток, некоторые с зависимостями друг от друга, которые вливаются в develop и релиз в разные моменты времени.
m> Полагаю, что раз выбран такой подход, то таски у них не пересекаются по коду (такое может быть и на больших проектах).
Вполне верю. Просто он это описал как альтернативу стандартного flow. Нет уж, стандартный flow вполне универсален, а предложенное выше работает только в определённых тепличных условиях.

m>А если так случится, что пересекаются, то сделают промежуточную ветку task01+task02.
Угу, много чего интересного может случиться (где например хотфиксы в его схеме?), и появятся новые магические ветки. И в итоге у них получится кривоватое подмножество flow.

m> ·>Т.е. тестироваться будет не тот код, который релизится. Опасно.
m> А это и так будет, потому что фичи могли в develop тестироваться вместе, а в release попасть в разное время. Или вообще фичу могут по результатам тестирования отложить до лучших времен.
m> Очевидно, что все это будет надежно, только если фичи независимы.
Угу. Притом независимость — нетривиальное свойство, т.е. без серьёзного доказательства и исследования определить независимость фич невозможно.