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, губитак података), безбедносна рањивост захтева хитно затварање или је покварена критична пословна логика (плаћања, ауторизација). Ако баг није критичан — може се исправити у оквиру редовног циклуса издања кроз 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 (како би се исправка сачувала у следећем издању). Прво се креира спајање у 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 гарантује креирање комита спајања, чак и ако би се 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 провере.