Comments 8
нам пришлось слезть с git-flow — нет ветки, где можно тестировать накапливающиеся хотфиксы.
Использую очень простой, но понятный 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.
Каждый хотфикс лучше оформлять одним целым комитом (можно с подкомитами), чтобы по возможности протестировать различные комбинации кумулятивных хотфиксов.
Никакой ерунды по поводу слияния changes в release ветку не делаю, так как запросто можно потерять суть происходящего. Hotfix вещь очень дорогая для тестирования и поставки, поэтому изменения должны быть максимально прозрачны. Изменения перекидываю из мастера в ветку чудо-командой git cherry-pick.
Каждый хотфикс лучше оформлять одним целым комитом (можно с подкомитами), чтобы по возможности протестировать различные комбинации кумулятивных хотфиксов.
Мы ушли от такого варианта, потому что нам приходилось делать копии конфигураций в TeamCity на каждый релизный бранч (компиляция, тесты, сборка пакета, в сумме 5-6 конфигов), к тому же если делать хотфикс в релизном бранче, есть шанс забыть сделать cherry-pick назад в master (лучше, конечно, как в вашем варианте — из master)
несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).
В смысле не ясен? Те коммиты, что были замержены, будут и в релизе.
Материал частично перекликается с git-flow, но здесь описан более простой вариант.
Ага, дополнительный странный бранч намного «проще».
Если вся разработка ведется в одной ветке, в которую идут активные мержи (и разработчиков много), то состав релиза зависит от момента сборки. Если build-машина собирает на каждое обновление репозитория, то у нас может в итоге получиться много разных сборок «version 1.0».
Это подходит для варианта «nightly build», но не для major-релиза. Это имелось в виду.
Насчет «проще» — вещь индивидуальная. Нам так удобнее, я лишь предложил вариант.
Это подходит для варианта «nightly build», но не для major-релиза. Это имелось в виду.
Насчет «проще» — вещь индивидуальная. Нам так удобнее, я лишь предложил вариант.
В классическом примере разработка ведется в master ветке?
У нас тоже собирается автоматически major релиз, но проблем таких с gitflow нет. Мержит один человек и билд получается только один.
Вообще, кажется что у вас абсолютно тот же git flow, только в оригинале отдельная ветка используется для разработки (develop), а у вас для релиза (release).
У нас тоже собирается автоматически major релиз, но проблем таких с gitflow нет. Мержит один человек и билд получается только один.
Вообще, кажется что у вас абсолютно тот же git flow, только в оригинале отдельная ветка используется для разработки (develop), а у вас для релиза (release).
Sign up to leave a comment.
Простой релиз-менеджмент средствами Git