Как правильно делать hotfix-ы для предыдущих релизов в рамках git flow?

Question

[Святослав Хусамов]

Допустим я создал релизы 1.0.0 и 1.1.0
Потом пользователи 1.0.0 начали жаловаться, в итоге надо делать сборку 1.0.1 с исправлениями багов. Потому что они на 1.1.0 переходить не хотят.
И как мне в рамках git flow это делать?
У меня на master-е уже сидит 1.1.0.
Если я сделаю 1.0.1, то эти изменения пойдут на ветку master и develop. В итоге 1.1.0 будет перезаписан! Причем с конфликтами.
Как быть?

Answer 1

[dmitriy]

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

Comments

[Святослав Хусамов]

Первый вариант, следущая версия выпущена, но до тестировщика не добралась (такое часто бывает, так как процесс перехода в тестирование медленный). А он нашел баги в предыдущей версии. В итоге новая версия есть, но появился список багов для старой. Че делать? По идее надо баги исправить в предыдущей, выпустить исправление (меняется последняя цифра версии) и отдать ее в эксплуатацию.

[dmitriy]

Первый вариант, следущая версия выпущена, но до тестировщика не добралась

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

Answer 2

[Fyzu]

Создать ветку на релизе 1.0.0, сделать фиксы и сделать релиз в этой ветке, ну и в дальнейшем поддерживать эту ветку.

Comments

[Святослав Хусамов]

То есть в git flow этот вариант сценария не предусмотрен?

Если я там сделаю фиксы, то они по идее должны попасть в 1.1.0 тоже. Но как сделать туда слияние не испортив версию 1.1.0? Например, как самое простое, при слиянии номер версии сменится с 1.1.0 на 1.0.1 в файле package.json и прочих файлах, содержащих номер версии.

Или вручную делать одни и те же фиксы во всех версиях? Коих, кстати, кроме 1.1.0, может быть несколько.

[Александр Бушманов]

Святослав, cделали ветку от 1.0.0, накоммитили туда, "отрезали" версию, потом в мастер чери-пик.

[Святослав Хусамов]

Александр Бушманов, Что значит Отрезали Версию? И чери пик это что?

[Александр Бушманов]

Святослав, под отрезали версию подразумевал навешивание тэга на коммит. Про cherry-pick и rebase
Советую все же Вам ознакомится с основами git и исходя из полученных знаний выбрать свое, подходящее Вам, flow.

[Святослав Хусамов]

Спасибо за ответ! Не думаю что черри пик это основы)) Гляну, может он поможет. А что, кроме git flow есть еще какие-то flow? Я просто больше не находил. Выбирать не из чего!

[Дмитрий]

Святослав, прочитайте про GitHub Flow и поймете, что в git каждый волен выбирать свою речку...
ЗЫ: Ну а про cherry-pick должен знать каждый, кто создал хотя бы одну ветку, тем более что это просто как три рубля.

[Святослав Хусамов]

Дмитрий, я имел ввиду готовый к использованию flow (со своими готовыми командами), а не просто описание.

[Дмитрий]

Святослав, я просто не вижу принципиальной разницы между:
git flow feature start MYFEATURE и
git checkout -b MYFEATURE
ну и далее по списку.
Ставить git-flow, чтобы потом говорить что "мы используем некий flow" - бредовая затея. Если вы понимаете как работает git, как делать ветки, слияния и т.п., то вы можете все те же операции выполнять обычными командами git, а значит вам ничего не стоит использовать любой более удобный для вас flow, например, GitHub Flow.

[Святослав Хусамов]

Дмитрий, это все понятно) Но на свой вопрос ответа так и не получил. Есть ли еще готовые flow или нет... не ясно. Он же четко написал:

> выбрать свое, подходящее Вам, flow.

Хотелось бы ознакомиться с ними. Или он пустое написал?

[Дмитрий]

Святослав, у вас просто концептуальная ошибка: вы считаете что flow это нечто железобетонное и их какое-то конечное число. Вот вы сейчас кодите и у вас уже есть свое flow, если он вам нравится, то продолжайте кодить так.
Flow - это просто жизненный путь кода от коммита до релиза. Будете ли вы делать ветки, будете ли вы мерджить или ребейзить - это просто соглашение между вами и соучастниками. Обратите внимания, что git-flow, который вы установили, по сути, не имеет отношения к git как к таковому (кроме того, что без него не работает), он даже устанавливается отдельно.
Вот вам мое flow - у меня только одна ветка, в которой я разрабатываю новый функционал, а фиксю я прямо в master. Но в этом проекте я работаю один и это flow меня полностью устраивает.
Если у вас большой проект с заморочками - используйте git-flow, если вы часто обновляете продакшен - используйте GitHub Flow, если вам не подходит ни то, ни другое, то придумайте собственный flow.
А использовать git-flow только по тому, что там можно написать git flow start release по меньшей мере глупо.

[Святослав Хусамов]

Дмитрий, да не кипятитесь вы так)))
Вот, ссылка на гит-флоу https://github.com/nvie/gitflow
Я вот хотел узнать, есть ли еще такие же готовые модули. Модули, а не описания. А вы снова описание присылаете, хоть и свое.

А вот по поводу глупо это или нет вы как-то не в тему. Мне это было предложено Александром Александр Бушманов . Вот я у него и спрашивал, какие еще есть, чтобы выбрать. Может кто знает.

Answer 3

[Sly_tom_cat .]

На мой взгляд, вопрос болше "политический". чем технический.

Версии поддерживаемые нужно четко отделить от не поддерживаемых.
Так к примеру есть у меня проектик на питоне, и был он изначально на Python v2.7, но в какой-то момент меня достала "поддержка" юникода во втором питоне. Переполз на 3-й, но т.к. на некоторых платформах есть проблемы с отдельными библиотеками для третьего питона ветку со вторым питоном я отделил и объявил - "для ветки второго питона - только хотфиксы".
Ветка третьего питона уже так далеко ушла от второго, так что там фиксы для второго один в один просто не подойдут уже. Т.е. один и тот же код фикса я просто уже не могу влить в обе ветки (там в третьем питоне весь код уже переделан на ООП, а во втором - там чисто процедурный подход).

Вот примерно так я вижу и вашу ситуацию. Если люди хотят фикс в старой версии - то ваше право сделать одно из двух:
1. Отказать, сказав что старая версия более не поддерживается,
2. Сделать фикс в старую версию и отдельно сделать фикс в новую (вполне возможно что один в один код для фикса в новой может отличаться от фикса в струю)

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

Comments

[Святослав Хусамов]

Спасибо за ответ. Думал что есть какие-то уже готовые решения в самом git flow.