Какой должен быть git workflow, что бы можно было безболезненно поддерживать старые версии проекта?

Question

[kicumkicum]

Привет. Мы разрабатываем фреймворк и библиотеки к нему, с помощью которых делаем проекты. В качестве методологии ветвления используем gitflow, и все было хорошо, когда версии библиотек шли друг за другом. То есть 0.1, 0.2...0.40

Но пришло осознание, что версии нужно давать правильно. Мы решили использовать семвер, и как раз выкатили большие обновления, сломали обратную совместимость. Версии пошли 1.0, 1.1, 1.2

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

Гитфлоу такое поведение не регламентирует, на сколько я понял. Нельзя создать хотфикс из 0.40 и влить его в мастер, в котором уже 1.2.

Я видел, что в репе node.js на гитхабе создаются отдельные ветки на каждый релиз: release-v6.x, release-v5x. Но не понял, как они с ними работают.

Отсюда возникает возникает вопрос. Может быть кто то знает и использует методологию, с которой эти проблемы решаются сами собой. И может быть даже есть инструмент, который будет все делать сам, как git-flow :)

Гуглить пробовал. Находил предложение legacy-релизы перемещать в support/* но идея мне кажется так себе.

Comments

[Владимир]

ваш случай это обычный hotfix, делается hotfix бранча с release/0.1, делаются все необходимые изменения и хотфикс мерджится обратно в бранчу. Далее стоит задача обновить другие бранчи которые ушли далеко вперед: develop, master другие релиз бранчи. Если разница небольшая (по коду не по версиям), то можно просто замержить (merge) хотфикс бранчу прямо в бранчу с релизом, dev, master. Если разница существенная то придется таргет бранчу ребейзить (rebase) на бранче хотфикса (т.е обновлять всю историю). Чтоб не решать одни и те же проблемы с мердж конфликтами можно мержить так (если первая проблемная бранча 0.2):
0.2 = 0.2 + hotfix (merge), 0.3 = 0.3 + 0.2 (уже с hotfix, rebase), 1.0 = 1.0 + 0.3 (уже с hotfix, rebase) итд итп.

[kicumkicum]

Владимир: так ветки release/0.1 нет. Она же закрывается при git flow release finish.
Не совсем понял про
> Если разница существенная то придется таргет бранчу ребейзить (rebase) на бранче хотфикса
Можете подробней рассказать?

[Владимир]

kicumkicum: Merge добавляет коммиты в конец истории, rebase перезатирает всю историю встраивая коммиты в середину дерева (что иногда может упростить задачу мерджа, но может и усложнить т.к. придется мержить всю историю c возникшим конфликтом). Поэтому лучше тренироватся в бранчах-клонах. Иногда хотфикс проще заново прикрутить в новой версии чем 3 дня мерждить историю изменений за пол года из за конфликта с хотфиксом.

[Владимир]

kicumkicum: касательно ветки - даже если ветки нету все равно ее состояние сохранилось в истории девелопа или же мастера. В девелопе/мастере должен быть коммит merged release branch 0.1, 0.3, 0.5 итд итп

Answer 1

[aol-nnov]

> Я видел, что в репе node.js на гитхабе создаются отдельные ветки на каждый релиз:
и
> предложение legacy-релизы перемещать в support/*

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

Comments

[kicumkicum]

Я и не собирался :) В 4ом абзаце как раз об этом написал.
Если в support/ помещать мастеры для легаси, то не понятно, что с ними потом делать.

Вот у нас есть баг во всех версиях. Делаем feature start - фикс - feature finish. A потом?
Думаю, можно переключиться на support/0.0.x и сделать cherry-pick фикса. Потом бампнуть версию, поставить тег. Вроде норм. Но мне кажется, что есть подвох.

Есть опасение, что если потребуется бекпортировать нетривиальную фичу, и она так просто не черепикнется.

[aol-nnov]

kicumkicum: https://github.com/nvie/gitflow/wiki/Command-Line-...
git flow feature start [-F] []
стартуйте фичу от сапорта сразу, и потом закрывайте. то есть, у вас будет отдельный флоу на старую версию, отдельный на новую.
черри-пикать можно руками безо всяких флоу.

[aol-nnov]

парсер скушал галочки.. по ссылке синтаксис посмотри....

[kicumkicum]

то есть, в саппорте будет ветка, с одноветочным флоу, правильно? В ней идет и разработка через фичи, и в ней же инкрементится версия. Я правильно понял?

[aol-nnov]

kicumkicum: ну, я бы так сделал.. и сильно бы надеялся, что это легаси надолго не затянется ;)
ты можешь и полноценный гитфлоу нашарашить на сапрот-ветке, только у тебя будет вместо мастера и девелопа свои, другие ветки в support/* и эти ветки надо будет указывать в командах гит флоу руками.

[kicumkicum]

это был бы идеальный вариант, но там есть нюанс :)
когда я делал git flow release start 0.0.41 legacy/0.0.x, то века создавалась откуда надо.
но при git flow release finish один мердж-комит шел в legacy/master/0.0.x, а другой в develop.
в конфиге ничего, что позволяло бы соотнести legacy/master и legacy/develop я не нашел

[aol-nnov]

kicumkicum: вот конфигурационные ключи https://github.com/nvie/gitflow/wiki/Config-values
их можно передавать при запуске прямо git -c gitflow.branch.develop=legacy/0.0.x/develop итд.
алиасов можно, например, нашарашить...

[kicumkicum]

О! блин, я как то это упустил из виду. Хотя были уже мысли переписывать конфиг хуками)) Спасибо большое. Думаю, это то что нужно :)

Answer 2

[Максим Мосейчук]

Но ведь по gitflow support-ветки как раз и предназначены для поддержки старых релизов без вливания в мастер.

Comments

[aol-nnov]

что-то я тут (danielkummer.github.io/git-flow-cheatsheet/) не обнаружил сапорт-веток... сам я давно гитфлоу забросил - мне не лень три команды набрать руками )

[Максим Мосейчук]

aol-nnov: Ой, ну вы нашли откуда информацию актуальную брать.

[kicumkicum]

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