Тупенький вопрос по GitFlow

если тебе нужно держать несколько стейблов, тогда нужны ветки. иначе нафиг не нужны

Что такое «релизная ветка»? Обычно релиз просто тегируется, коммиты пушатся в одну или несколько dev-веток, которые при релизах мержатся в master.

Логическое завершение добавления новых фич приемв нее только правок, не?

Почему бы просто не пушить в dev?

Существование релизной ветки не мешает пушить в dev.

На старой работе у нас была релизная ветка, dev-ветка, qa-ветка и feature-ветки. И я тогда даже помнил, что куда должно коммититься.

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

Чтобы иметь гарантированно рабочую версию. dev может быть сломан в какой-то момент.

Хотфиксы и бэкпорты никто не отменял

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

Это в первом приближении.

Но они же не в ту же ветку накатываются, разве нет? Или как-то все равно должно разделяться что зарелизили, и что добавилось после релиза

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

Профит в том, что в develop это время можно безболезненно вести разработку, не боясь испортить выпускаемую версию.

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

Если ветка именно релизная типа release-15.04, то в неё и накатывается.

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

А как потом это контролировать? Вот у пользователя стоит release-15.04, при чем код был собран в какой-нибудь пакет, то есть по сути ты не знаешь какой там коммит последний. Пользователь жалуется что есть проблемы, а в коде из репозитория эта проблема не воспроизводится, потому что там куча патчей уже

Обычно бампают минорную версию, не?

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

а апдейт небесплатный если в случае коммерческого продукта?

в рамках мажорной версии обычно бесплатный же.

Если апдейт не бесплатный то ты сам знаешь какую версию ты ему продал.

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