Как можно эффективно использовать git-flow в проекте, в котором поддерживается более одной основной версии?

Я перенес несколько своих проектов в рабочий поток Git Flow, и мне это нравится. Тем не менее, я не нашел лучшей практики, которая бы работала так гладко при работе с проектом, в котором одновременно поддерживается более одной основной версии.

В частности, я не поддерживаю «бесплатную версию» и «платную версию» или любую другую параллельную модель, я говорю о проекте, в котором выпущена Версия 1, и которая поддерживается второстепенными версиями (1.1, 1.2 и т. Д.). .) до тех пор, пока не будет выпущена версия 3, при которой точки 2 и 3 будут поддерживаться, пока не будет выпущена версия 4 ... вы поняли идею.

Как вы поддерживаете две или более поддерживаемые версии проекта одновременно в рабочем процессе gitflow?

git workflows gitflow

— HedgeMage
источник

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

— ProdigySim

@ProdigySim: Спасибо за данные, но это только я, или это добавило бы определенное количество накладных расходов для отслеживания и управления?

— HedgeMage

@ProdigySim Я подозреваю, что эти проекты не использовали инструмент с возможностями ветвления и слияния git.

— Рейн Хенрикс

@ Rein Они используют Mercurial. Я не думаю, что ветвление было бы очень чистым с точки зрения отслеживания параллельных основных версий программного обеспечения.

— ProdigySim

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

— Рейн Хенрикс

Ответы:

man gitworkflowsдедушка рабочего процесса 'git flow' описывает общие рекомендации по рабочему процессу git; использованиеpu , next, masterи maintветвей; и как maintуправляется. Если у вас есть несколько веток обслуживания, вы можете назвать их, например maint/1.x, maint/2.xи так далее.

Ключ не столько в том, как использовать команды git, сколько в том, как построить разумный процесс. Решите, какие вещи важны для вас (простота переноса?) И создайте (и задокументируйте) рабочий процесс, который удовлетворяет этим ограничениям.

— Рейн Хенрикс
источник

Но отвечает ли это на вопрос? А именно, поддерживает ли git-flow гибкую модель выпуска, как описано в вопросе, или можно вернуться к базовым командам git? («gitworkflows» описывает базовое использование рабочего процесса git, pre-git-flow.) Git-flow был создан (якобы) для упрощения процессов слияния / ветвления git, поэтому команды (с различной степенью мастерства git-fu) могли сосредоточиться на кодировании и избежать трудоемких ошибок "слияния". Можно ли с помощью git-flow поддерживать и развивать v1.2. {1,2,3, ..} одновременно с v2.5. {1,2,3, ...}? Возможно, с долгосрочным выпуском веток? Или master1, master2, ...?

— Майкл

В принципе, вы бы дублировать master, releaseи developветвь для каждой основной версии вы поддерживаете. Как они взаимодействуют друг с другом, остается прежним. Для featureотраслей, просто убедитесь , что отделение от самой старой ветви , которую вы собираетесь объединить обратно в , который предотвращает тянущую нежелательные зависимости. Затем, когда вы объединяете свою featureветвь, вы просто делаете дополнительные слияния с каждой соответствующей более новой ветвью основной версии.

— Карл Билефельдт
источник

Разве весь смысл мастера не включать каждую выпущенную версию?

— HedgeMage

@HedgeMage, в более линейном цикле выпуска это так, но это очень непрактично для параллельных основных версий.

— Карл Билефельдт

Это кажется наиболее практичным решением, если только не существует проверенного способа использования исправлений или чего-то такого, о чем я не знаю. Я искал способ представить git-flow и по-прежнему иметь возможность (как неблагоприятное условие) сохранить нашу существующую модель выпуска, где мы должны поддерживать / разрабатывать более старые версии (не только исправления). Таким образом, v5.1.x будет работать (с добавлением новых функций, исправлением ошибок и т. Д.) Через пару лет после выпуска v6.1.x. Около 2-3 основных версий поддерживаются и разрабатываются в любой момент времени. Но исправления ошибок должны быть применены к каждой версии, где ошибка существует.

— Майкл