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

30

Я пытаюсь выбрать рабочий процесс 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, кажется, что легче исправить в ветке, а затем у меня есть релиз, к которому я всегда могу вернуться это последнее исправление (я могу даже пометить исправления в выпуске). Не уверен, что есть способ вернуться в мастер и каким-то образом получить копию выпуска с примененными исправлениями и обновить этот тег.

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

Rocket04
источник
11
Я знаю о git-flow, но я не понимаю, как он работает с несколькими одновременными выпусками. Похоже, что ветки релизов даже не созданы для какой-либо работы, в основном для очистки, а затем слияния и тегирования. Что мне делать, если у меня есть исправление, которое влияет на 4 разных версий выпуска? Полагаю, я мог бы оформить помеченный релиз от master, но как только я исправлю его, как бы я переделал все исправления, которые я сделал в master для этого конкретного релиза. Похоже, это будет довольно сложно.
Rocket04
Если вам нужно оперативно исправить несколько выпусков одним и тем же исправлением, вам, вероятно, следует сначала исправить самую старую версию и объединить ее с более новой, адаптируясь под каждый выпуск. Если вы работаете от нового к старому, вы рискуете удалить зависимости от более поздних выпусков, что усложнит ситуацию.
Axl
И, как я упоминаю в предложенном ответе, основная ветвь не очень хорошо работает с несколькими живыми выпусками, поэтому, если вам она действительно не нужна по какой-то причине, я бы посоветовал вам ее не использовать.
Axl

Ответы:

9

Похоже, что вы выполняете разветвление в каждом основном выпуске (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" , Это кажется очень сложным для поддержания в целом, но это было бы возможно.

Axl
источник
3

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

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

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

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

sentenza
источник
1

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

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

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

Габор Ангьял
источник
Но, как я уже говорил, в случае с git-flow совсем не похоже, что они вообще используют ветки релизов. Не похоже, что там происходит какое-то серьезное развитие. Также кажется, что ветвь разработки является бесполезной, если мы в основном работаем с ветвями релиза, а может просто избавиться от нее, каждая ветвь релиза по сути является ветвью разработки в течение определенного периода времени. Или я что-то упустил?
Rocket04