Відгалуження: лише за необхідності, за несумісною політикою, із запізненням і замість заморожування
Лаура Вінгерд і Крістофер Сейвальд (технічний документ високого рівня ‘SCM Best Practices’ 1998 року від ‘Perforce’)
Якщо команда випускає робочі релізи щомісяця, то їм також доведеться випускати релізи з виправленням помилок між запланованими релізами. Для цього команди, що використовують Trunk-Based Development, часто створюють релізну гілку завчасно, наприклад, за кілька днів до релізу. Це стає стабільним місцем, оскільки розробники продовжують активно комітити зміни в основну гілку. Несумісна політика (див. Wingerd & Seiwald вище) стверджує, що релізна гілка «не повинна отримувати продовження розробки».
Хто тут комітить?
Розробники комітять (зелені крапки) при найвищій пропускній здатності до стовбура, і не сповільнюються та не зависають навколо зрізу гілки чи наближення до релізу. Розробники як група не комітять в гілку релізу (див. нижче).
Сам зріз гілки є комітом. Subversion і Perforce технічно мали б тут більший коміт, але всі системи VCS, які використовуються сьогодні, вважали б коміт «легким» з точки зору його впливу на історію/сховище та часу, витраченого на створення. Ця червона крапка є випадковим зривом збірки, який було виправлено (якимось чином) незабаром після цього.
Пізнє створення гілок релізу
Деякі команди випускають релізи безпосередньо з тегу на основній гілці, не створюючи гілку на той момент. Це є альтернативною практикою до «гілки для релізу». Такі команди чекають на помилку, яку потрібно виправити після випуску, і лише тоді створюють гілку з релізного тегу (якщо вони не планують просто випустити ще один реліз з основної гілки). Бред Епплтон зазначає, що багато хто не усвідомлює, що гілки можна створювати ретроспективно (заднім числом). Це використовується у випадках, коли після “випуску з тегу” потрібно виправити помилки або внести зміни для додаткових релізів.
Виправлення виробничих помилок на гілці Trunk
Найкраща практика для команд, що використовують Trunk-Based Development, полягає в тому, щоб відтворити помилку на основній гілці, виправити її там разом з тестом, переконатися, що вона пройшла перевірку CI-сервером, а потім вибрати цю зміну (cherry-pick) в гілку релізу та зачекати, поки її також перевірить CI-сервер, орієнтований на гілку релізу. Так, CI-пайплайн, який захищає основну гілку, буде дублюватися для захисту активних релізних гілок також.
Черрі-пік не є звичайним злиттям
Черрі-пік злиття бере певний комміт (або коміти) і об’єднує його з гілкою призначення. Він пропускає один або кілька комітів, які відбулися до нього, але після того, як гілку було вирізано. Усі інструменти VCS відстежують, які коміти було об’єднано, а які ні, тож пізніше ви можете зробити більше вибору.
Черрі-піки ТІЛЬКИ із Trunk до гілки Ви не повинні виправляти помилки на гілці релізу, очікуючи, що черрі-піки збиратимуть їх назад в Trunk. Чому? Ну на випадок, якщо ви у поспіху забудете це зробити. Забуття означає регрес у виробництві через кілька тижнів (і когось звільнять). Це може статися, якщо втомлений розробник, який хоче повернутися спати, лагодить речі вночі.
Це правило для Trunk-Based Development іноді важко прийняти, навіть для команд, які дотримуються всіх інших аспектів Trunk-Based Development. Проте достатньо одного регресу, щоб команда змінила свою політику. Звичайно, іноді зовсім неможливо відтворити помилку на основній гілці. У цьому випадку доведеться діяти по-іншому, незважаючи на все сказане вище, але розуміти, що ви вводите ризик регресії.
Патч релізів
Можливо, ваша команда пушила випуск із гілки релізу, і тепер має помилку, яку потрібно виправити у розробці. Якщо версія релізу підходить, то підійде черрі-пік виправлення помилок із Trunk до гілки релізу і випустити точковий реліз з цієї ж гілки.
Тег замість гілки
Реліз від тегу на гілці Trunk є гідною оптимізацією для багатьох команд, якщо це можливо. Тег можна пронумерувати для релізу (скажімо, v1.1.1), і гілки можна повністю уникнути. Можливо, якщо у виробництві буде виявлено помилку, гілку буде створено ретроспективно (заднім числом) з цього тегу, і звідти можна буде випустити патч (див. вище).
Видалення гілки релізу
Гілки релізу видаляються через деякий час після припинення діяльності з релізу. Не відразу, але коли буде зрозуміло, що реліз більше не у виробництві. Гілки випуску НЕ об’єднуються назад у Trunk. Зазвичай це відбувається тоді, коли релізи з наступних гілок релізів починають працювати. Це нешкідлива операція з очищення — гілки можна знову досить легко відновити в усіх варіантах VCS. У git потрібно створити тег із випущеного коміту перед видаленням гілки релізу, оскільки вивішені коміти збиратимуть сміття.