Подскажите пожалуйста. У меня есть ветка "девелоп" и ветка "релиз". Они существуют

параллелльно, и в них параллельно коммитится код.
В "девелоп" коммитятся новые фичи.
В "релиз" коммитятся багфиксы.
Как лучше сделать чтобы багфиксы из релиза попадали в девелоп?
Обычно советуют мержить "релиз" в "девелоп" после того как релиз выйдет в прод, но это не известно когда произойдёт. А багфиксы из "релиза" мне нужны в "девелоп" уже сейчас, потому что эти баги афектят новые фичи.

делаешь всё правильно !

А процессом ветвления в проекте рулите лично вы?

в том числе я, могу что-то изменить если требуется

Кто принял решение держать две параллельные ветки дев-релиз? Лично вы, лично кто-то другой, группа людей с вами или без вас?

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

Начальство — инженеры или менеджеры? Если менеджеры, то они могут решить "надо релизить фичи скопом, при этом при багах делаем релизы с багфиксами". Скажите, вы ранее в этом чате уже спрашивали совета по текущей ситуации?

нет, первый раз спрашиваю. Начальство - инженеры так решили.

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

прямолинейно простой рецепт - это какой?

Любой. У вас принято делать МРы? Делаете МРы.

То есть как только багфикс был вмержен в релизную ветку, сразу же мержить релизную ветку в девелоп?

Это может привести к новым багам же. Если ветки по фичам уже разошлись (а они у вас расходятся), то фикс следует тестировать на обеих ветках. Плюс обнаружение бага в релизной ветке не гарантирует, что он будет и в девелопе. QA-инженерам в случае бага следует перепроверять обе ветки на наличие бага. И обе же ветки на факт починки бага.

Эта модель изначально несостоятельна по следующей причине Если в девелоп замеджено будет 10 фич, а начальство хочет в следующий релиз половину из них, то может быть очень больно формировать новую релиз-ветку

Тут от начальства зависит. Я до сих пор не до конца понимаю, чем грозит релиз багфикса с частью новых фич.

У бизнеса часто бывают нюансы. Релиз некоторых фичей должен координироваться между департаментами или даже не дай бог 3д-пати партнёрами

За таких остается только молиться.

да не то что бы больно, скорее всего просто будет сделана ветка релиза, в которой будет 10 фич, а эти 5будут просто отключены в коде. То есть спрятать кнопку, не обрабатывать нажатие, и прочее

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

у меня как раз такой случай, большой финтех

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

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

То есть у вас аж три долгоживущих ветки.

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

да, мастер - это прод, девелоп - это основна ветка куда сливаются все фичи, и релиз - живет не долго, мержится в мастер после тестирования