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 е необходим в три сценария: критичен бъг блокира потребителите (срив, загуба на данни), уязвимост в сигурността изисква незабавно затваряне или е счупена критична бизнес логика (плащания, оторизация). Ако бъгът не е критичен — може да бъде коригиран в рамките на обичайния цикъл на пускане чрез 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 чрез директни commits в 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 трябва да съдържа минимален брой промени. Не рефакторирайте кода и не добавяйте нови функционалности — само точкова корекция, която отстранява проблема.

Записване на корекцията

Commit в hotfix трябва да има информативно съобщение, което недвусмислено описва проблема и неговото решение. Формат: тип(област): кратко описание + препратка към задачата в тракера.

# Добавете променените файлове
git add src/ui/login/LoginActivity.kt

# Създайте commit с описание
git commit -m "fix(login): handle null intent on activity resume

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

Съобщението на commit-а трябва да съдържа описание на проблема и препратка към задачата. Това улеснява търсенето в историята и помага на колегите да разберат какво е коригирано и защо. За мобилни проекти обикновено се посочва и версията на приложението, в която е открит бъгът.

Сливане в main и develop

Последна стъпка — слейте hotfix обратно в main (с етикет на новата версия на пача) и в develop (за да се запази корекцията в следващото пускане). Първо се създава сливане в main с етикет, след това сливане в 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 гарантира създаването на commit за сливане, дори ако hotfix може да бъде приложен чрез fast-forward. Това запазва информацията, че е извършена спешна корекция, и улеснява анализа на историята в бъдеще.

Разлика между Hotfix и Feature и Release

Hotfix се различава принципно от feature и release клоновете по цел, живот и правила на сливане. Разбирането на тези различия е критично за правилната организация на Git процесите в екипа.

Feature клонът е предназначен за нова функционалност. Той живее от няколко дни до няколко седмици, създава се от develop и се слива обратно в develop. Feature може да съдържа много commits, включително експериментални, които впоследствие се компресират чрез 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), а не minor (v2.4.0) или major (v3.0.0). Нарушаването на семантичното версиониране обърква системата за изграждане и заблуждава потребителите.
• Липса на CI проверки — дори спешен hotfix трябва да преминава автоматични тестове. Пропускането на CI увеличава риска от въвеждане на нова грешка. Препоръчва се да има отделен pipeline за hotfix клонове с ускорени проверки.

Всяка от тези грешки води до забавяне на пускането на пача или до появата на нови проблеми в продукционната среда. Екипите трябва да фиксират правилата за работа с hotfix в CONTRIBUTING.md и да ги автоматизират чрез CI/CD проверки.