с использованием git для поддержки старых версий

Question

Я читал о рабочих потоках git и, похоже, было предположение, что ветви существуют для целей разработки, и все в конечном итоге сливается обратно в master. Я не могу много обсуждать использование длинных ветвей для обслуживания старых версий.

Например, вот как работает мой рабочий процесс в SVN (основанный на модели «tofu»). Скажем, последняя выпущенная версия - 4.1, но я также поддерживаю версии 4.0, 3.5 и 3.6, поэтому для каждой из них есть ветвь обслуживания. Багажник используется для функций, которые не будут выпущены до 4.2. Теперь скажите, что клиенту требуется исправление ошибки до версии 3.6. Я сделаю исправление в моей ветке обслуживания 3.6 и сделаю новый релиз обслуживания (ради аргумента, 3.6.22).

На этом этапе исправление сливается вниз в 4.0 и оттуда до 4.1, 4.2 и ствола, а оттуда - в любые ветви развития, созданные из ствола. Обратите внимание, что это не слияние вишни; это обычное автоматическое слияние SVN.

Если исправление является нетривиальным, мы можем сделать ветвь dev из ветки выпуска 3.6, а затем реинтегрировать ее обычным способом перед выпуском. Аналогичным образом, если слияние до 4.1 является нетривиальным, мы можем создать ветку разработки из 4.1, чтобы объединиться и затем реинтегрировать ее обратно в версию 4.1, когда мы довольны слиянием.

Когда мы выпускаем версии 4.2 мы ответвляются ветви обслуживания для этого таким же образом, и ствол будет продолжающийся 4,3 работы

Должен ли я (или даже я) использовать точно такой же рабочий процесс в мерзавца, или это традиционное мышление «старой шляпы», которое нужно пересмотреть?

Answer 1

Стратегии ветвления на самом деле не сильно меняются в зависимости от технологии управления версиями. То, что вы описали, похоже на довольно стандартный ветвящийся рабочий процесс для живого продукта. Что изменилось бы при переходе на Git из другого инструмента, такого как SVN, это , стоимость создания и обслуживания ветки. В Git ветвление чрезвычайно дешево. Ветвь в Git в основном является указателем на фиксацию. Таким образом, стоимость, например, создания ветки обслуживания, содержащей только несколько коммитов, будет поэтапно очень мала. Возможно, это не так с инструментом SVN, где может потребоваться создать копию или каждый файл в проекте.