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

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

Изучи гит для начала.

нет, в этом как раз и соль черрипика: https://git-scm.com/book/ru/v2/%D0%9F%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5-C%3A-%D0%9A%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D1%8B-Git-%D0%92%D0%BD%D0%B5%D1%81%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B8%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9

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

Да, плохо еще его знаю..

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

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

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

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

https://nvie.com/posts/a-successful-git-branching-model/

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

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

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

порочная система, лучше работать под gerrit, он спрямляет историю, что делает работу легче и интуитивно понятнее

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

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

Stop cherry-picking, start merging

https://devblogs.microsoft.com/oldnewthing/20180323-01/?p=98325

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

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

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

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

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

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

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

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

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

А что делать когда этот блок кода 5 лет как выпилен из мастера но есть у части версий?

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

значит фиксить в одном из бранчей и черипикать туда, где актуально

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

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

gitflow

Зачем ты эту какашку сюда притащил?

А что там не так, если конструктивно?

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

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

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

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

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

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

Глянем, спасибо.

ну голову-то никто не отменял, а сдуру все что угодно сломать можно

А вы помните все изменения во всех ветках? Особенно те которые делали не вы?

бисти дело говорит

да, потому что я на эти изменения ревью делаю

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

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

да, потому что я на эти изменения ревью делаю

+1. Вот это правильный подход.

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

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

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

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

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

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

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

я посмотрел на https://nvie.com/posts/a-successful-git-branching-model/ и мне стало плохо от одной мысли об этом.

Не, конечно только https://trunkbaseddevelopment.com/

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

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