Відповідний робочий процес Git для декількох активних випусків під час обробки виправлень

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

• Ми робимо кілька великих релізів на рік, скажімо, щонайбільше 10
• У нас є декілька версій нашого продукту, які одночасно активні (деякі люди перебувають на версії 1010, інші на версії v11.2 тощо)
• Нам потрібно мати можливість працювати над кількома випусками одночасно (щоб ми могли працювати над v12.1, але, як дістатися до кінця випуску, ми почнемо працювати над v12.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 завершений, об'єднайте його у головну та теги головного відділення з 12.1
• Якщо потрібне виправлення, створіть гілку виправлень із найдавнішої гілки випуску, яка потребує її, введіть зміни та об'єднайтесь назад у всі гілки випуску для цього випуску та майбутніх випусків, на які можна вплинути; якщо була постраждала остання гілка стабільного випуску, об'єднайте її в головний.

У мене є кілька проблем:

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

Цінуються коментарі щодо речей, які я, можливо, не помічав, або кращих способів їх виконання, враховуючи вимоги, які я вказав.

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

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

Я б дотримувався GitFlow і вніс кілька поправок;

Пропустіть головну гілку. Я до цього часу не використовував його практично, і він втрачав би свою лінійність, як ви працюєте. Продовжуйте розробку наступного великого випуску на розробці. Якщо ви вирішили зберегти майстер, не ставте теги випуску на майстер, накладіть їх на останню команду у гілці випуску, яка створила двійковий файл, який ви відправляєте.

Не викидайте гілки випуску після того, як ви з’єднаєте їх назад для розвитку. Замість цього тримайте їх біля наступного незначного випуску та можливих виправлень. Якщо ви коли-небудь перестанете підтримувати випуск, я думаю, добре їх видалити. Ви можете назвати гілки випуску після їх основного компонента, release / 12, а потім створити гілки під випуском, release / 12.1, release / 12.2 off. Мені не доводилося надто турбуватися про цей рівень паралелізму, але це, мабуть, те, що я б спробував. У цьому випадку кожну велику гілку випуску можна розглядати як власне середовище sub-GitFlow.

Якщо ви повинні паралельно працювати над функціями для декількох майбутніх великих релізів одночасно, можливо, вам доведеться зберегти наступний (13) про розробку, а що-небудь для пізніших версій (14, 15) на додаткових гілках "розвивати-N" . Це, здається, загалом важко підтримувати, але було б можливо.

Здається, що можливим рішенням вашої основної проблеми ( «Нам потрібно вміти працювати над кількома випусками одночасно [...]» ) - це створенняgit worktree add <path> [<branch>]

Репозиторій git може підтримувати декілька робочих дерев , дозволяючи перевіряти кілька гілок одночасно.
З git worktree add, нове робоче дерево асоціюється із сховищем.

Це нове робоче дерево називається "пов'язаним робочим деревом" на відміну від "основного робочого дерева", підготовленого " git init" або " git clone" .
У сховищі є одне основне робоче дерево (якщо воно не є голим сховищем) та нульове або більше пов'язаних робочих дерев.

Дивіться цю відповідь ТА для детального вступу на git worktree.

Ви згадали, що вам знайомий gitflow. Я пропоную додати його до вашого сценарію. Вам потрібно буде створити гілки зі своєї галузі розробки для підтримки старих версій. Ці старі версії також повинні мати власні випуски / головні гілки та гілки виправлень. Вам потрібно буде періодично об’єднувати свої гілки підтримки у новіші гілки підтримки та гілки розвитку.

У міру того, як розробка основних версій розходиться, це буде все складніше. Срібної кулі для цього немає. Іноді зміни вручну буде простіше зробити. Витрати на підтримку старих версій збільшаться, і в якийсь момент це вже не варто.

Все залежить від того, які зміни ви вносите в своїх старих версіях. Якщо лише виправлення помилок, то злиття порівняно просто. Якщо ви спробуєте додати нові функції, це буде важко.