Hotfix Branch: ce este, cum se creează și se aplică în dezvoltarea mobilă

Ce este Hotfix Branch?

Hotfix Branch — este o ramură temporară în Git, care este creată pentru remedierea operativă a defectelor critice în producția activă. Spre deosebire de ramurile feature, care se ramifică din develop și trăiesc câteva zile sau săptămâni, hotfix este creat din main/master și există exact atât cât este necesar pentru remedierea bug-ului.

Sarcina principală a hotfix — minimizarea timpului între detectarea erorii critice și remedierea ei în producție. Echipa nu așteaptă finalizarea sprintului curent sau a ciclului de lansare, ci publică patch-ul imediat. Acest lucru este deosebit de important pentru aplicațiile mobile, unde un bug critic poate bloca utilizatorii și poate duce la pierderea acestora.

Potrivit datelor Google Play Console, timpul mediu de moderare a actualizării în Google Play este de la 2 la 24 de ore. Pentru App Store revizuirea expres poate dura de la 1 la 4 ore. Ramurile hotfix permit pregătirea remedierii chiar înainte de finalizarea moderării și implementarea ei imediat după aprobare.

Principiul de funcționare a Hotfix

Procesul hotfix constă din trei pași: crearea ramurii din main, aplicarea remedierii și fuzionarea înapoi în main și develop. Diferența cheie față de o remediere obișnuită — hotfix este întotdeauna fuzionat în ambele ramuri, pentru ca remedierea să nu se piardă la următoarea lansare.

Echipa nu trebuie să adauge în hotfix funcționalități noi sau refactorizări. Doar o remediere punctuală, minim necesară pentru eliminarea problemei critice. Orice abatere de la această regulă crește riscul de regresie și întârzie timpul de lansare a patch-ului.

Când este necesar Hotfix

Hotfix este necesar în trei scenarii: bug-ul critic blochează utilizatorii (crash, pierdere de date), vulnerabilitatea de securitate necesită închidere imediată sau logica de business critică este stricată (plăți, autentificare). Dacă bug-ul nu este critic — poate fi remediat în cadrul ciclului obișnuit de lansare prin develop.

Pentru aplicațiile mobile hotfix poate include și modificări server, dacă arhitectura permite comutarea de la distanță a funcțiilor (feature flags). În acest caz, ramura hotfix poate fi minimă sau poate să nu fie deloc necesară, dacă remedierea se face pe partea de server.

Modele de ramificare și locul Hotfix

Nu toate modelele de ramificare suportă ramurile hotfix. Git Flow tradițional prevede hotfix ca un tip complet de ramură, iar abordările mai moderne (GitHub Flow, Trunk-based) rezolvă problema remedierilor de urgență altfel.

Git Flow și Hotfix

Git Flow — este singurul model în care hotfix este un tip încorporat de ramură alături de feature și release. În Git Flow hotfix este creat din main, iar după finalizare este fuzionat atât în main (cu tag de versiune), cât și în develop. Aceasta garantează că remedierea nu se va pierde în următoarea lansare.

GitHub Flow și Trunk-based

GitHub Flow nu folosește un tip separat de ramură pentru hotfix. În schimb, dezvoltatorul creează o ramură obișnuită feature din main, aplică remedierea și deschide un Pull Request. După revizuire și verificări CI, ramura este fuzionată în main și implementată imediat. Avantajul — simplitate, dezavantajul — lipsa unui canal separat pentru remedieri urgente.

Trunk-based rezolvă problema hotfix prin commit-uri directe în main (pentru cazuri critice) cu revizuire obligatorie post factum. Această abordare necesită disciplină înaltă a echipei și teste automate fiabile, deoarece modificările ajung în producție instantaneu.

Cum se creează Hotfix Branch

Crearea hotfix începe cu comutarea pe ramura principală și crearea unei ramuri noi cu prefixul hotfix/. Să examinăm procesul pas cu pas pe exemplul remedierii unui bug critic într-o aplicație mobilă.

Crearea ramurii din main

Primul pas — comutați pe main și asigurați-vă că ramura este actualizată. Apoi creați o ramură hotfix cu un nume clar care reflectă esența remedierii.

# Comutați pe main și obțineți ultimele modificări
git checkout main
git pull origin main

# Creați o ramură hotfix
git checkout -b hotfix/crash-on-login

După crearea ramurii se poate aplica remedierea. Important: hotfix trebuie să conțină un număr minim de modificări. Nu trebuie să refactorizați codul sau să adăugați funcționalități noi — doar remedierea punctuală care elimină problema.

Înregistrarea remedierii

Commit-ul în hotfix trebuie să aibă un mesaj informativ care descrie fără ambiguitate problema și soluția ei. Format: tip(domeniu): descriere scurtă + link către sarcina din tracker.

# Adăugați fișierele modificate
git add src/ui/login/LoginActivity.kt

# Creați un commit cu descriere
git commit -m "fix(login): handle null intent on activity resume

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

Mesajul commit-ului trebuie să conțină descrierea problemei și link către sarcină. Aceasta simplifică căutarea în istoric și ajută colegii să înțeleagă ce a fost remediat și de ce. Pentru proiectele mobile se indică de obicei și versiunea aplicației în care a fost descoperit bug-ul.

Fuzionarea în main și develop

Pasul final — fuzionați hotfix înapoi în main (cu tag-ul noii versiuni patch) și în develop (pentru ca remedierea să se păstreze în următoarea lansare). Mai întâi se creează fuzionarea în main cu tag, apoi fuzionarea în develop.

# Fuzionați în main și creați un tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Fuzionați în develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Trimiteți modificările pe server
git push origin main --tags
git push origin develop

Flag-ul --no-ff garantează crearea unui commit de fuzionare, chiar dacă hotfix ar putea fi aplicat prin fast-forward. Aceasta păstrează informația că a fost efectuată o remediere de urgență și simplifică analiza istoricului în viitor.

Diferența dintre Hotfix și Feature și Release

Hotfix se deosebește fundamental de ramurile feature și release prin scop, durata de viață și regulile de fuzionare. Înțelegerea acestor diferențe este esențială pentru organizarea corectă a proceselor Git în echipă.

Ramura feature este destinată funcționalității noi. Trăiește de la câteva zile la câteva săptămâni, este creată din develop și fuzionată înapoi în develop. Feature poate conține multe commit-uri, inclusiv experimentale, care ulterior sunt comprimate prin squash sau rebase.

Ramura release pregătește lansarea pentru publicare. Este creată din develop, în ea se remediază bug-urile găsite în procesul de stabilizare și nu acceptă funcționalități noi. După finalizare, release este fuzionată în main (cu tag) și develop.

Hotfix însă este creat și fuzionat direct cu main, ocolind develop (deși după remediere se sincronizează și cu develop). Conține un număr minim de modificări și există pentru un timp minim. Dacă feature sau release pot fi amânate până la următorul ciclu, hotfix — nu.

Pentru dezvoltarea mobilă această diferență este deosebit de importantă: App Store și Google Play permit lansarea versiunilor patch separat de lansările principale. Ramura hotfix asigură un proces în care lansarea patch-ului nu se amestecă cu funcțiile neterminate.

Erori tipice la lucrul cu Hotfix

Erorile la lucrul cu hotfix pot anula avantajele remedierii de urgență. Să examinăm cinci probleme frecvente care apar în echipele care folosesc Git Flow.

• Crearea hotfix din develop — dacă hotfix este creat din develop, în patch pot ajunge funcții neterminate. Hotfix trebuie creat doar din main pentru a garanta că remedierea include doar cod stabil.
• Mai multe remedieri într-un singur hotfix — fiecare remediere trebuie să fie într-o ramură hotfix separată. Amestecarea mai multor bug-uri într-o singură ramură complică revizuirea codului, crește riscul de regresie și îngreunează revenirea la o versiune anterioară.
• Omisiunea fuzionării în develop — dacă hotfix nu este fuzionat în develop, remedierea se va pierde la următoarea lansare. Echipa va descoperi că același bug a reapărut și va fi nevoită să-l remedieze din nou.
• Tag de versiune incorect — hotfix trebuie să primească un increment de patch (v2.3.0 → v2.3.1), nu minor (v2.4.0) sau major (v3.0.0). Încălcarea versionării semantice dereglează sistemul de build și derutează utilizatorii.
• Lipsa verificărilor CI — chiar și un hotfix de urgență trebuie să treacă testele automate. Omiterea CI crește riscul de introducere a unei noi erori. Se recomandă să existe un pipeline separat pentru ramurile hotfix cu verificări accelerate.

Fiecare dintre aceste erori duce la întârzierea lansării patch-ului sau la apariția unor noi probleme în producție. Echipele ar trebui să stabilească reguli de lucru cu hotfix în CONTRIBUTING.md și să le automatizeze prin verificări CI/CD.