LINUX.ORG.RU

Поддержка нескольких веток ПО в Git

 ,


0

1

Всем привет!

Имеется некоторый продукт, у которого выпущено уже большое количество версий. По определенным причинам заказчики не всегда спешат менять минорные версии продукта. Таким образом для разных заказчиков поддерживаются несколько веток, допустим актуальные 1.2, 1.3, 1.4 и master, где разрабатывается будущий 1.5 в рамках выпущенных минорных версий исправляем только багфиксы и к примеру заказчик в версии 1.2.5 заметил ошибку, ее исправили в версии 1.2.6. Исправление нужно распространить на 1.3, 1.4 и master, допустим выпустив новые патч-релизы 1.3.8, 1.4.2. Исправления для выпуска 1.2.6 делались в отдельных багфик-ветках и пулреквестом заливались в ветку 1.2.6.

Вопрос - как лучше поступить? Создавать отдельные пулреквесты из багфикс-веток в 1.3.8 и 1.4.2, master или после выхода 1.2.6 сделать большой пулреквест в 1.3.8 и 1.4.2 и мастер из 1.2.6? Или просто смерджить? Вопрос лежит больше в чистоте логов гит и простоте поддержки версий.


Ответ на: комментарий от EugeneBas

о, большое спасибо! я подумал, что черипикать это какое-то слово заменитель, типа засандалить-зафутболить.

sotlef ()

девелопишь мастер, в бранчи клиентов черрипикаешь.

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

Думаешь, как прекратить эту бессмысленную трату жизни и делать как гугл, держа всех на мастере.

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

очень просто, достаточно лишь вырасти до размеров гугла, а пока не вырос - прогибаешься под кастомеров

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

делать как гугл, держа всех на мастере.

С точки зрения гита тег ничем не отличается от ветки. Переключаешся на тег, изменяешь, коммитишь и ставишь новый тег, вот тебе и ветка (если не поставить, сборщик мусора почистит)

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

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

С точки зрения гита тег ничем не отличается от ветки.

Как раз отличается иначе не нужно было бы ставить новый тег после коммита. Тег к коммиту прибит и сам по себе не измениятся, а ветка обновляется.

xaizek ★★★★★ ()

Черепикать имхо не очень.

Исправил в 1.1, влил в 1.2, потом уже 1.2 влил в 1.3 и 1.3 в мастер

zerhud ()

жизненный хинт : поддерживать своё древо в ином VCS. Это тупо проще и нервов меньше

то есть твоя контора шабашников (или ты один) пусть работает в SVN (fossil/mercurial). А тим-лид стеблит значимые этапы вверх. (и вниз наоборот)

ну да, получаются два дерева.. зато все жизненные проблемы разруливаются

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

Придираешься к логике работы при коммите, а не к тому, чем является «ветка» и «тег».

Ветка и тег - это просто ссылки на коммит. Это просто именнованные узлы в дереве коммитов. Ветка - это не совокупность коммитов, это всего лишь ссылка на узел-коммит. Как и тег.

Разница только в логике работы при коммите. Если HEAD - ветка, то при коммите автоматически обновляется ссылка ветки. Если нет, эта логика пропускается и создается неименованный узел в дереве (detached), который удалится про сборке мусора.

Так что ветки для версий не нужны, если нет прям острой необходимости.

anonymous ()
Ответ на: комментарий от sotlef

Заглядывай в ман по гиту, там еще много чего интересного найдешь

EugeneBas ★★ ()

Чирипикай однозначно, самый удобный вариант.

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

Подход всё равно так себе. В therac тоже черри-пикнули софтовую защиту в новую версию автомата. Вот только физической пластины в новой версии не было. Так же и с полностью софтовыми проектами - в другой ветке может быть изменение которое дебалансит черри-пикнутое исправление.

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

Конструктивно – попробуй, поймёшь, какой это ад. Нерабочий высер кукоретика, которой все почему-то хайпят (но никто на самом деле не использует, потому что это просто ад).

На hello-world проектах оно то выглядит конфеткой. Но «было ровно на бумаге, да забыли про овраги». В реальном мире оно не жизне-способно.

Как уже сказали выше – cherry-pick и ручками майнтейнить старые версии.

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

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

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

Вряд ли это «ликбез». Скорее моё «фэ» к этому подходу. Для одно-разовый вещей оно нафик не сдалось. Для более сложных вещей (AKA real-life madness) – это административный ад.

Я больше склоняюсь к https://trunkbaseddevelopment.com/

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

гугл так не делает trunk based development не исключает релизных бранчей в которых ничего нет кроме мелких фиксов

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

Не надо работать под gerrit. Серьёзно, не надо. Мне сейчас как раз приходится, и это удивительное говно.

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

у меня прямо противоположные впечатления, видимо, дело вкуса

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

товарищ Мигель не оценил геррит, а я вот его как раз таким образом настроил, чтобы ни одно изменение мимо меня не прошло

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

делать как гугл, держа всех на мастере.

это где такое? chromium?

anonymous ()
  • зависит от реализации самой архитектуры/дизайна софта:
    • модульность, зависимости, разбиение на независимые пакеты, use-флаги и т.д.
  • немного оффтопик, но посмотрите git subrepo

Возможен такой подход:

  • есть мастер-ветка, где последние изменения
  • есть ветка, которая базовая для всех клиентских веток
    • с нее подливать в остальные
    • потихоньку рефакторить что можно и не затратно
  • почитывать про микроядра и монолитные ядра, альтернативы
anonymous ()

Ответ на данный вопрос содержится в политике ведения версий, которую вы выбрали. В gitflow надо создать багфикс ветку от самого старого из поддерживаемых релизов, пофиксить, смержить, потом смержить во все последующие релизы и в девелоп. Получится страшный граф в истории версий, но, благодаря тому, что все релизы образуют одну линию, всё должно смержиться нормально. В thunk-based исправляешь в thunk потом мержишь (а возможно и черрипикаешь) в релиз и обнаруживаешь, что нифига не работает, потому как фикс основан на свежем коде, так что каждый перенос на более старую ветку это фактически фикс заново.

Одно важно знать: если ты что-то черрипикнул между двумя ветками, то готовься к тому, что смержить что-то между ними будет нельзя. Для гита черрипик - это то же самое, что руками внести 2 одинаковых изменения в 2 ветки, это конфликт. Сам по себе черрипик - это тоже своего рода мерж (точнее рибейз + мердж + чистка), только без сохранения истории, поэтому и черрипики со временем станут проблемными. Это важно знать, так как система со многими поддерживаемыми релизами обычно означает рашен флоу, когда для солидного клиента А сделано большое улучшение, достаточное для бампа версии с 1.3 до 1.4, в то время как не менее солидный клиент Б сидит на 1.2.37 и для него тоже сделано много дополнительных наворотов, нужных только ему, при этом менеджеры пытаются развести его на апгрейд до 1.4. Так вот, если у них получится, то потребуется все эти навороты Б смержить в 1.4, а если ты забавлялся черрипиками, то готовься к боли. Так что думай, что важнее, красивый граф истории или возможность за вменяемое время привести ветку в актуальное состояние.

khrundel ★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.