Простой релиз-менеджмент средствами Git

[@asm0dey]

нам пришлось слезть с git-flow — нет ветки, где можно тестировать накапливающиеся хотфиксы.

[@vics001]

Использую очень простой, но понятный flow. Для каждой major версии создается ветка v1.0.0, v1.5.0, дальше именно с этой ветки выпускаются релизы. Например, в ветке v1.0.0 могут быть теги v1.0.0, v1.0.1 или pre1.0.0a, pre1.0.0b

Никакой ерунды по поводу слияния changes в release ветку не делаю, так как запросто можно потерять суть происходящего. Hotfix вещь очень дорогая для тестирования и поставки, поэтому изменения должны быть максимально прозрачны. Изменения перекидываю из мастера в ветку чудо-командой git cherry-pick.
Каждый хотфикс лучше оформлять одним целым комитом (можно с подкомитами), чтобы по возможности протестировать различные комбинации кумулятивных хотфиксов.

[@seregamorph]

Мы ушли от такого варианта, потому что нам приходилось делать копии конфигураций в TeamCity на каждый релизный бранч (компиляция, тесты, сборка пакета, в сумме 5-6 конфигов), к тому же если делать хотфикс в релизном бранче, есть шанс забыть сделать cherry-pick назад в master (лучше, конечно, как в вашем варианте — из master)

[@vics001]

В этом случае вам все равно ничего не мешает завести ветку lastRelease и простенький build script. git reset --HARD lastRelease origin/v1.0.0.
Я к тому, что вам повезло, если вы поддерживаете только один стабильный релиз :) Если у вас их несколько, чаще всего нужен быстрый доступ ко всем.

[@m_z]

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

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

Материал частично перекликается с git-flow, но здесь описан более простой вариант.

Ага, дополнительный странный бранч намного «проще».

[@seregamorph]

Если вся разработка ведется в одной ветке, в которую идут активные мержи (и разработчиков много), то состав релиза зависит от момента сборки. Если build-машина собирает на каждое обновление репозитория, то у нас может в итоге получиться много разных сборок «version 1.0».
Это подходит для варианта «nightly build», но не для major-релиза. Это имелось в виду.
Насчет «проще» — вещь индивидуальная. Нам так удобнее, я лишь предложил вариант.

[@m_z]

В классическом примере разработка ведется в master ветке?

У нас тоже собирается автоматически major релиз, но проблем таких с gitflow нет. Мержит один человек и билд получается только один.

Вообще, кажется что у вас абсолютно тот же git flow, только в оригинале отдельная ветка используется для разработки (develop), а у вас для релиза (release).

[@seregamorph]

Да, в master. Если мержит один человек, проблемы нет. Мы используем gerrit, замержить может любой ревьюер после прохождения ревью.
Кстати, про git flow мы узнали не так давно — как раз при подготовке статьи, думаем его попробовать.