Hotfix Branch: що це, як створювати та застосовувати в мобільній розробці

Що таке Hotfix Branch?

Hotfix Branch — це тимчасова гілка в Git, яка створюється для оперативного виправлення критичних дефектів у працюючому продакшені. На відміну від feature-гілок, які відгалужуються від develop і живуть кілька днів або тижнів, hotfix створюється від main/master та існує рівно стільки, скільки потрібно для виправлення багу.

Основне завдання hotfix — мінімізувати час між виявленням критичної помилки та її виправленням у продакшені. Команда не чекає завершення поточного спринту або релізного циклу, а випускає патч негайно. Це особливо важливо для мобільних додатків, де критичний баг може заблокувати користувачів і призвести до відтоку.

За даними Google Play Console, середній час проходження модерації оновлення в Google Play — від 2 до 24 годин. Для App Store експрес-рев'ю може зайняти від 1 до 4 годин. Hotfix-гілки дозволяють підготувати виправлення ще до того, як пройде модерація, і викачати його одразу після апруву.

Принцип роботи Hotfix

Процес hotfix складається з трьох кроків: створення гілки від main, внесення виправлення та злиття назад у main і develop. Ключова відмінність від звичайного фіксу — hotfix завжди зливається в обидві гілки, щоб виправлення не загубилося при наступному релізі.

Команда не повинна вносити в hotfix новий функціонал або рефакторинг. Тільки точкове виправлення, мінімально необхідне для усунення критичної проблеми. Будь-яке відхилення від цього правила збільшує ризик регресії та затягує час випуску патча.

Коли потрібен Hotfix

Hotfix необхідний у трьох сценаріях: критичний баг блокує користувачів (crash, data loss), вразливість безпеки потребує негайного закриття, або зламана критична бізнес-логіка (платежі, авторизація). Якщо баг не критичний — його можна виправити в рамках звичайного релізного циклу через develop.

Для мобільних додатків hotfix також може включати серверні зміни, якщо архітектура дозволяє перемикати функції віддалено (feature flags). У цьому випадку hotfix-гілка може бути мінімальною або взагалі не знадобиться, якщо виправлення робиться на стороні сервера.

Моделі розгалуження та місце Hotfix

Не всі моделі розгалуження підтримують hotfix-гілки. Традиційний Git Flow передбачає hotfix як повноцінний тип гілки, а більш сучасні підходи (GitHub Flow, Trunk-based) вирішують завдання екстрених виправлень інакше.

Git Flow та Hotfix

Git Flow — єдина модель, де hotfix є вбудованим типом гілки нарівні з feature та release. У Git Flow hotfix створюється від main, а після завершення зливається і в main (з тегом версії), і в develop. Це гарантує, що виправлення не загубиться в наступному релізі.

GitHub Flow та Trunk-based

GitHub Flow не використовує окремий тип гілки для hotfix. Натомість розробник створює звичайну feature-гілку від main, вносить виправлення та відкриває Pull Request. Після рев'ю та перевірок CI гілка зливається в main і одразу деплоїться. Перевага — простота, недолік — відсутність окремого каналу для термінових виправлень.

Trunk-based розробка вирішує завдання hotfix через коміти безпосередньо в main (для критичних випадків) з обов'язковим рев'ю постфактум. Цей підхід потребує високої дисципліни команди та надійних автоматичних тестів, оскільки зміни потрапляють у продакшен миттєво.

Як створити Hotfix Branch

Створення hotfix починається з перемикання на основну гілку та створення нової гілки з префіксом hotfix/. Розглянемо покроковий процес на прикладі виправлення критичного багу в мобільному додатку.

Створення гілки від main

Перший крок — переключитися на main і переконатися, що гілка актуальна. Потім створити гілку hotfix із зрозумілим ім'ям, що відображає суть виправлення.

# Переключитися на main та отримати останні зміни
git checkout main
git pull origin main

# Створити hotfix-гілку
git checkout -b hotfix/crash-on-login

Після створення гілки можна внести виправлення. Важливо пам'ятати: hotfix повинен містити мінімальну кількість змін. Не слід рефакторити код або додавати нові можливості — тільки точкове виправлення, яке усуває проблему.

Фіксація виправлення

Коміт у hotfix повинен мати інформативне повідомлення, яке однозначно описує проблему та її рішення. Формат: тип(область): короткий опис + посилання на задачу в трекері.

# Додати змінені файли
git add src/ui/login/LoginActivity.kt

# Створити коміт з описом
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

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

Злиття в main та develop

Фінальний крок — злити hotfix назад у main (з тегом нової патч-версії) та в develop (щоб виправлення збереглося в наступному релізі). Спочатку створюється merge в main з тегом, потім — merge в develop.

# Злити в main та створити тег
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Злити в develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Відправити зміни на сервер
git push origin main --tags
git push origin develop

Флаг --no-ff гарантує створення коміту злиття, навіть якщо hotfix можна було б застосувати через fast-forward. Це зберігає інформацію про те, що було виконано екстрене виправлення, та спрощує аналіз історії в майбутньому.

Відмінність Hotfix від Feature та Release гілок

Hotfix принципово відрізняється від feature та release гілок за метою, часом життя та правилами злиття. Розуміння цих відмінностей критично важливе для правильної організації Git-процесів у команді.

Feature-гілка призначена для нової функціональності. Вона живе від кількох днів до кількох тижнів, створюється від develop та зливається назад у develop. Feature може містити безліч комітів, включаючи експериментальні, які згодом стискаються через squash або rebase.

Release-гілка готує реліз до випуску. Вона створюється від develop, у ній виправляються баги, знайдені в процесі стабілізації, і вона не приймає новий функціонал. Після завершення release зливається в main (з тегом) та develop.

Hotfix же створюється та зливається безпосередньо з main, минаючи develop (хоча після виправлення синхронізується і з develop). Він містить мінімальну кількість змін та існує мінімальний час. Якщо feature або release можуть бути відкладені до наступного циклу, hotfix — ні.

Для мобільної розробки ця відмінність особливо важлива: App Store та Google Play дозволяють випускати патч-версії окремо від основних релізів. Hotfix-гілка забезпечує процес, при якому патч-реліз не змішується з незавершеними фічами.

Типові помилки при роботі з Hotfix

Помилки при роботі з hotfix можуть звести нанівець переваги екстреного виправлення. Розглянемо п'ять найбільш частих проблем, які виникають у командах, що використовують Git Flow.

• Створення hotfix від develop — якщо hotfix створюється від develop, у патч можуть потрапити незавершені фічі. Hotfix повинен створюватися тільки від main, щоб гарантувати, що у виправлення включений тільки стабільний код.
• Кілька виправлень в одному hotfix — кожне виправлення повинно бути в окремій hotfix-гілці. Змішування кількох багів в одній гілці ускладнює код-рев'ю, підвищує ризик регресії та ускладнює відкат при необхідності.
• Пропуск злиття в develop — якщо hotfix не злити в develop, виправлення буде втрачено при наступному релізі. Команда виявить, що той самий баг з'явився знову, і буде змушена виправляти його повторно.
• Некоректний тег версії — hotfix повинен отримувати патч-інкремент (v2.3.0 → v2.3.1), а не мінорний (v2.4.0) або мажорний (v3.0.0). Порушення семантичного версіонування збиває систему збірки та плутає користувачів.
• Відсутність CI-перевірок — навіть екстрений hotfix повинен проходити автоматичні тести. Пропуск CI збільшує ризик внесення нової помилки. Рекомендується мати окремий pipeline для hotfix-гілок із прискореними перевірками.

Кожна з цих помилок призводить до затримки випуску патча або до появи нових проблем на продакшені. Командам варто зафіксувати правила роботи з hotfix у CONTRIBUTING.md та автоматизувати їх через CI/CD-перевірки.