Соответствующий рабочий процесс Git для нескольких активных выпусков при работе с исправлениями

Я пытаюсь выбрать рабочий процесс Git, наиболее подходящий для нашего продукта. Вот параметры:

• Мы выпускаем несколько крупных релизов в год, скажем, 10 максимум
• У нас одновременно работает несколько версий нашего продукта (некоторые люди на v10.1, некоторые на v11.2 и т. Д.)
• Нам нужно иметь возможность работать над несколькими выпусками одновременно (чтобы мы могли работать над версией 12.1, но когда мы подойдем к концу релиза, мы начнем работать над версией 12.2 одновременно)
• Мы должны иметь возможность исправлять выпуски при обнаружении критических ошибок

Пока что я думаю, что это может сработать:

• Один удаленный репо используется
• Создать ветку 12.1 от мастера
• Создайте ветки объектов на основе 12.1, зафиксируйте их и объедините в 12.1, нажмите
• Как только нам нужно начать работу над будущим выпуском, создайте новую ветку 12.2 на основе 12.1
• С этого момента, при работе над функцией для 12.1, создайте ветку из 12.1, зафиксируйте изменения и объединитесь в 12.1 и 12.2, нажмите
• Если вы работаете над функцией для 12.2, создайте ветку из 12.2, зафиксируйте изменения и объединитесь только в 12.2, нажмите
• Когда выпуск 12.1 будет завершен, объедините его с главной веткой master и tag с 12.1
• Если требуется исправление, создайте ветку исправления из самой старой ветки выпуска, которая нуждается в нем, внесите изменения и объедините все ветки выпуска для этого выпуска и будущих выпусков, которые могут быть затронуты; если была затронута последняя ветка стабильного выпуска, объедините ее с master.

У меня есть несколько проблем:

• Я не уверен, что объединение исправлений из старых веток в новые будет гладким процессом, особенно если было много пересекающихся изменений; Было бы разумнее просто исправлять вручную в каждой ветви в тех случаях, когда это выглядит как конфликты
• Модели рабочих процессов, которые я видел, по-видимому, не поддерживают живую ветвь релиза, после того как релиз слит в мастер, помечен и удален. Моя проблема в том, что у меня нет хорошей идеи, как управлять состоянием релиза, если все, что у меня есть, это теги в master, кажется, что легче исправить в ветке, а затем у меня есть релиз, к которому я всегда могу вернуться это последнее исправление (я могу даже пометить исправления в выпуске). Не уверен, что есть способ вернуться в мастер и каким-то образом получить копию выпуска с примененными исправлениями и обновить этот тег.

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

Похоже, что вы выполняете разветвление в каждом основном выпуске (12.0.0), затем возможны незначительные обновления для каждого (12.1.0) и оперативные исправления (12.2.1). Правильный?

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

Я бы придерживался GitFlow и сделал бы несколько поправок;

Пропустите главную ветку. До сих пор я не использовал его на практике, и он потерял бы свою линейность, как вы работаете. Продолжайте разработку в следующем основном выпуске. Если вы решили оставить master, не размещайте теги release на master, поместите их в последний коммит в ветке release, которая создала бинарный файл, который вы отправляете.

Не выбрасывайте ветки релизов после их объединения в разработку. Вместо этого держите их для следующего незначительного выпуска и возможных исправлений. Если вы когда-нибудь прекратите поддерживать релиз, я думаю, что его можно удалить. Вы можете назвать ветки релиза в честь их основного компонента, релиза / 12, а затем создать ветки вспомогательного релиза, релиз / 12.1, релиз / 12.2. Мне не приходилось слишком беспокоиться об этом уровне параллелизма, но, вероятно, я бы попробовал это сделать. В этом случае вы можете думать о каждой основной ветке релиза как о своей собственной среде GitFlow.

Если вы должны параллельно работать над функциями для нескольких будущих основных выпусков одновременно, возможно, вам придется оставить следующий (13) в разработке и что-нибудь для более поздних версий (14, 15) в дополнительных ветвях "развернуть-N" , Это кажется очень сложным для поддержания в целом, но это было бы возможно.

Похоже, что одно из возможных решений вашей основной проблемы ( «Нам нужно работать над несколькими выпусками одновременно [...]» )git worktree add <path> [<branch>]

Git-репозиторий может поддерживать несколько рабочих деревьев , что позволяет вам проверять более одной ветви за раз.
С git worktree addновым рабочим деревом связано хранилище.

Это новое рабочее дерево называется «связанным рабочим деревом», а не «основным рабочим деревом», подготовленным « git init» или « git clone» .
Репозиторий имеет одно основное рабочее дерево (если это не пустой репозиторий) и ноль или более связанных рабочих деревьев.

Смотрите этот SO ответ для подробного введения в git worktree.

Вы упомянули, что знакомы с gitflow. Я предлагаю добавить его для вашего сценария. Вам нужно будет создать ветки из вашей ветки разработки для поддержки более старых версий. Эти старые версии также должны иметь свои собственные ветки релиза / мастера и ветки исправлений. Вам нужно будет периодически объединять ваши ветви поддержки с новыми ветками поддержки и ветвью разработки.

Поскольку разработка основных версий расходится, это будет становиться все труднее. Для этого нет серебряной пули. Иногда будет проще внести изменения вручную. Стоимость обслуживания старых версий возрастет, и в какой-то момент это не будет стоить больше.

Все зависит от того, какие изменения вы делаете в своих старых версиях. Если только исправление ошибок, то это сравнительно легко объединить. Если вы попытаетесь добавить новые функции, это будет сложно.