LINUX.ORG.RU

Git workflow для cherry-pick релизов

 , ,


0

2

Приветствую!

Есть крупный проект в котором есть ветка основная dev в которую мы пилим весь функционал. А когда у нас случается релиз (1-5 раз в месяц), мы создаем ветку релиза к примеру 18.02.01 и туда мы сливаем (с помощью cherry-pick) только тот функционал который требует заказчик. Обычно 50% функционала не входит в релиз и так и валяется мертвым грузом на dev. Когда нужно посмотреть какие комиты отстались в dev и не вошли в релиз можно использовать `git cherry -v`, но из за конфликтов эта команда бесполезна.

Прошу совета у бывалых git юзеров, как лучше сделать git workflow для нашего случая

★★

cherry-pick релиз

Мне кажется, что если так не делать, то и проблем не будет. Зачем так вообще делать начали?

xaizek ★★★★★ ()

Вы не ответвляетесь от dev для каждой фичи (с последующим merge) а валите в одну ветку се что ли?

micronekodesu ★★ ()
Ответ на: комментарий от micronekodesu

Судя по описанию так и есть.

ТС, завязывайте наркоманию, для каждой фичи держите свою ветку, смерживайте в dev только нужное для релиза, релиз тегируйте, и не будет никакого головняка на эту тему. Если хотите продолжать страдать, то вам никто не поможет. Здравый смысл не печеньки — его не отсыпать. (%

r3lgar ★★★★★ ()
Ответ на: комментарий от r3lgar

Если в одном дереве исходники под нескольких клиентов, которым разные релизы, что как я подозреваю у топикстартера, то там не проканает, только страдать.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

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

ex3me ★★ ()
Ответ на: комментарий от micronekodesu

Вы не ответвляетесь от dev для каждой фичи (с последующим merge) а валите в одну ветку се что ли?

Иногда ответвляемся, иногда нет. В нашем случае это не обязательно. У каждого таска есть уникальный номер «task-23672» и можно найти все комиты в ветке dev

git log --pretty=format:"%H%x09%an%x09%ad%x09%s" | egrep -i "task-23672"

Далее делаем git cherry-pick в релизную ветку и таск в нужной ветке.

ex3me ★★ ()
Ответ на: комментарий от xaizek

Мне кажется, что если так не делать, то и проблем не будет. Зачем так вообще делать начали?

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

ex3me ★★ ()
Ответ на: комментарий от ex3me

Можно подумать о скрипте, который составит список тасков в релизных ветках, а потом выведет список коммитов в мастере, которые относятся к другим таскам. Если бы не делали cherry-pick, то git log ... --not ... бы справился, но так как коммиты разные, то надо реализовать аналог.

xaizek ★★★★★ ()
Последнее исправление: xaizek (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

Ну тогда можно держать два-три-пять-тридцать dev-веток под каждого клиента со своим функционалом. Но юзать cherry-pick для релизов — это надо иметь очень больную фантазию.

r3lgar ★★★★★ ()
Ответ на: комментарий от r3lgar

И боль в синхронизации. Когда процесс разработки сломан, его как ни чини, всё равно плохо

Dark_SavanT ★★★★★ ()

не пользовался cherry pick - просто merge веток

- почему используется cherry-pick вместо обычного merge? это веь не очень удобно

- cherry-pick вроде как для отдельно взятых коммитов (возможно bisect еще), но как мне представляется: возникает задача контроля зависимостей от коммитов cherry-pick

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

anonymous ()

При работе с gerrit удобно использовать его change-id, по ним легко определить какие патчи были черрипикнуты а какие остались

Еще можно коментить патчи через git notes, см. например https://blog.adamspiers.org/2013/10/02/more-uses-for-git-notes/

annulen ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.