Исправление ошибок в старых выпусках в рабочем процессе, как описано Адамом Димитруком ("ветвь за компонентом")

Question

Я читал о рабочем процессе Адама Димитрука в Git, и все это имеет смысл.

Единственное, о чем я не могу говорить, это исправление ошибок в старых версиях. Изобразите "основную" ветку с тегами 7.0, 7.1, 7.2, 7.3, 7.4, 7.4.1, 7.4.2, 7.8, 8.2 и самой последней 8.3

В производстве для конкретного клиента находится версия 7.2, и ошибка найдена и должна быть исправлена.

Исправление в 8.3.1 и перемещение клиента с 7.2 на 8.3.1 неприемлемо для клиента.

Итак, есть ли рекомендуемый рабочий процесс для этого?

Я мог бы создать ветвь главной ветки из тега 7.2, вызвать эту ветку release-7.2.x Затем обработать 'release-7.2.x' так же, как каждый обрабатывает основную ветку - создать из базовой линии ветвь функции (72bug), исправьте ошибку и т. д. и, в конечном счете, объедините ветвь функции с 'release-7.2.x', сделайте сборку, сделайте тег 7.2.1 и запустите его в производство. В этом случае 'release-7.2.x' будет жить вечно, как и мастер, так что любые дополнительные исправления в 7.2.x могут быть сделаны в release-7.2.x.

Конечно, никто не хочет потерять исправление из 7.2 для текущей работы, поэтому можно создать ветку объектов из текущей основной базовой линии (8.3) и объединить ветку ошибок (72bug) с этой веткой функций. Эта ветвь функции будет рассматриваться как любая другая функция для текущего цикла выпуска / спринта. Таким образом, в конце цикла новейшая базовая линия (8.4) будет содержать исправление ошибки.

Как другие, использующие рабочий процесс Адама, справились с этой ситуацией?

Answer 1

Если вы не можете перенести клиент на текущую версию, тогда нет смысла начинать новую ветку с тега 7.2.

Однако вместо того, чтобы исправить ошибку в ветке 72bug и объединить ее как с веткой release-7.2.x, так и с веткой текущей функции, я бы предложил исправить ошибку в текущей ветке функции, а затем использовать git cherry-pick перенести исправление в ветку release-7.2.x. Это поможет сохранить вашу историю в чистоте, так что ваша текущая разработка не может внезапно зависеть от более старой версии просто из-за потребностей одного клиента.