Hotfix Branch: mi ez, hogyan hozzuk létre és alkalmazzuk mobilfejlesztésben

Mi az a Hotfix Branch?

Hotfix Branch — egy ideiglenes ág a Git-ben, amely a működő éles környezetben fellépő kritikus hibák operatív javítására jön létre. Ellentétben a feature ágakkal, amelyek a develop-ból ágaznak ki és néhány napig vagy hétig élnek, a hotfix a main/master-ből jön létre és pontosan addig létezik, amíg a hiba javításához szükséges.

A hotfix fő feladata — az idő minimalizálása a kritikus hiba észlelése és annak éles környezetben történő javítása között. A csapat nem vár a jelenlegi sprint vagy kiadási ciklus befejezésére, hanem azonnal kiadja a javítást. Ez különösen fontos a mobilalkalmazásoknál, ahol egy kritikus hiba blokkolhatja a felhasználókat és elvándorláshoz vezethet.

A Google Play Console adatai szerint a frissítés moderálásának átlagos ideje a Google Play-ben 2 és 24 óra között van. Az App Store esetében a gyorsított felülvizsgálat 1-4 óráig tarthat. A hotfix ágak lehetővé teszik a javítás előkészítését a moderálás befejezése előtt, és annak azonnali kiadását a jóváhagyás után.

A Hotfix működési elve

A hotfix folyamata három lépésből áll: ág létrehozása a main-ből, javítás elvégzése és visszaolvasztás a main-be és a develop-ba. A szokásos javítástól való kulcsfontosságú különbség — a hotfix mindig mindkét ágba beolvasztásra kerül, hogy a javítás ne vesszen el a következő kiadásnál.

A csapat ne adjon a hotfix-hez új funkcionalitást vagy refaktorálást. Csak pontszerű javítást, amely minimálisan szükséges a kritikus probléma megszüntetéséhez. Bármilyen eltérés ettől a szabálytól növeli a regresszió kockázatát és meghosszabbítja a javítás kiadásának idejét.

Mikor van szükség Hotfix-re?

Hotfix három forgatókönyv esetén szükséges: kritikus hiba blokkolja a felhasználókat (összeomlás, adatvesztés), biztonsági rés azonnali lezárást igényel, vagy a kritikus üzleti logika hibás (fizetések, hitelesítés). Ha a hiba nem kritikus — a szokásos kiadási ciklus keretében a develop-on keresztül javítható.

Mobilalkalmazások esetében a hotfix szerveroldali változtatásokat is tartalmazhat, ha az architektúra lehetővé teszi a funkciók távoli kapcsolását (feature flag-ek). Ebben az esetben a hotfix ág minimális lehet, vagy egyáltalán nem szükséges, ha a javítás a szerver oldalon történik.

Elágazási modellek és a Hotfix helye

Nem minden elágazási modell támogatja a hotfix ágakat. A hagyományos Git Flow a hotfix-et teljes értékű ágtípusként kezeli, míg a modernebb megközelítések (GitHub Flow, Trunk-based) másképp oldják meg a sürgős javítások problémáját.

Git Flow és Hotfix

Git Flow — az egyetlen modell, ahol a hotfix a feature és release mellett beépített ágtípus. Git Flow-ban a hotfix a main-ből jön létre, és befejezése után mind a main-be (verziócímkével), mind a develop-ba beolvasztásra kerül. Ez garantálja, hogy a javítás nem vész el a következő kiadásban.

GitHub Flow és Trunk-based

GitHub Flow nem használ külön ágtípust a hotfix számára. Ehelyett a fejlesztő egy szokásos feature ágat hoz létre a main-ből, elvégzi a javítást, és megnyit egy Pull Request-et. A felülvizsgálat és CI-ellenőrzések után az ág beolvasztásra kerül a main-be és azonnal telepítésre kerül. Előny — egyszerűség, hátrány — a sürgős javítások számára külön csatorna hiánya.

Trunk-based fejlesztés a hotfix problémáját közvetlen commit-okkal oldja meg a main-be (kritikus esetekben) kötelező utólagos felülvizsgálattal. Ez a megközelítés magas csapatfegyelmet és megbízható automatikus teszteket igényel, mivel a változtatások azonnal éles környezetbe kerülnek.

Hotfix Branch létrehozása

A hotfix létrehozása a főágra váltással és egy új, hotfix/ előtagú ág létrehozásával kezdődik. Tekintsük át a folyamatot lépésről lépésre egy mobilalkalmazás kritikus hibájának javításán keresztül.

Ág létrehozása a main-ből

Első lépés — váltson a main-re, és győződjön meg arról, hogy az ág naprakész. Ezután hozzon létre egy hotfix ágat egyértelmű névvel, amely tükrözi a javítás lényegét.

# Váltson main-re és töltse le a legújabb változtatásokat
git checkout main
git pull origin main

# Hozzon létre egy hotfix ágat
git checkout -b hotfix/crash-on-login

Az ág létrehozása után elvégezhető a javítás. Fontos: a hotfix-nek minimális számú változtatást kell tartalmaznia. Ne refaktorálja a kódot, és ne adjon hozzá új funkciókat — csak a problémát megszüntető pontszerű javítást.

A javítás rögzítése

A commit a hotfix-ben informatív üzenettel kell rendelkezzen, amely egyértelműen leírja a problémát és annak megoldását. Formátum: típus(terület): rövid leírás + hivatkozás a trackerben lévő feladatra.

# Adja hozzá a módosított fájlokat
git add src/ui/login/LoginActivity.kt

# Hozzon létre egy commit-et leírással
git commit -m "fix(login): handle null intent on activity resume

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

A commit üzenetének tartalmaznia kell a probléma leírását és egy hivatkozást a feladatra. Ez leegyszerűsíti a keresést az előzményekben, és segít a kollégáknak megérteni, mit és miért javítottak. Mobil projekteknél általában feltüntetik az alkalmazás verzióját is, amelyben a hibát felfedezték.

Beolvasztás a main-be és a develop-ba

Utolsó lépés — olvassza vissza a hotfix-et a main-be (az új javítási verzió címkéjével) és a develop-ba (hogy a javítás megmaradjon a következő kiadásban). Először a main-be történő beolvasztás jön létre a címkével, majd a develop-ba történő beolvasztás.

# Olvassza be a main-be és hozzon létre címkét
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Olvassza be a develop-ba
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Küldje el a változtatásokat a szerverre
git push origin main --tags
git push origin develop

A --no-ff zászló garantálja a beolvasztási commit létrehozását, még akkor is, ha a hotfix fast-forward segítségével alkalmazható lenne. Ez megőrzi az információt arról, hogy sürgős javítás történt, és leegyszerűsíti az előzmények elemzését a jövőben.

A Hotfix különbsége a Feature-től és a Release-től

A Hotfix alapvetően különbözik a feature és release ágaktól céljában, élettartamában és a beolvasztás szabályaiban. E különbségek megértése kritikus fontosságú a Git-folyamatok helyes megszervezéséhez a csapatban.

A feature ág új funkcionalitásra szolgál. Néhány naptól néhány hétig él, a develop-ból jön létre és oda is olvasztandó vissza. A feature sok commit-ot tartalmazhat, beleértve a kísérletieket is, amelyeket később squash vagy rebase segítségével tömörítenek.

A release ág a kiadást készíti elő. A develop-ból jön létre, benne a stabilizáció során talált hibákat javítják, és nem fogad új funkcionalitást. Befejezése után a release beolvasztásra kerül a main-be (címkével) és a develop-ba.

A hotfix viszont közvetlenül a main-ből jön létre és oda is olvasztandó, megkerülve a develop-ot (bár a javítás után a develop-bal is szinkronizálódik). Minimális számú változtatást tartalmaz, és minimális ideig létezik. Ha a feature vagy a release elhalasztható a következő ciklusig, a hotfix — nem.

A mobilfejlesztés szempontjából ez a különbség különösen fontos: az App Store és a Google Play lehetővé teszi a javítási verziók fő kiadásoktól elkülönített kiadását. A hotfix ág biztosítja azt a folyamatot, amelyben a javítási kiadás nem keveredik a befejezetlen funkciókkal.

Tipikus hibák a Hotfix használatánál

A hibák a hotfix használatánál semmissé tehetik a sürgős javítás előnyeit. Tekintsük át az öt leggyakoribb problémát, amelyek a Git Flow-t használó csapatoknál felmerülnek.

• Hotfix létrehozása a develop-ból — ha a hotfix a develop-ból jön létre, befejezetlen funkciók kerülhetnek a javításba. A hotfix-et csak a main-ből szabad létrehozni, hogy garantálni lehessen, hogy a javítás csak stabil kódot tartalmaz.
• Több javítás egy hotfix-ben — minden javításnak külön hotfix ágban kell lennie. Több hiba egy ágban történő keverése megnehezíti a kódellenőrzést, növeli a regresszió kockázatát, és szükség esetén megnehezíti a visszaállítást.
• A develop-ba olvasztás elmaradása — ha a hotfix nem kerül beolvasztásra a develop-ba, a javítás elveszik a következő kiadásnál. A csapat felfedezi, hogy ugyanaz a hiba újra megjelent, és kénytelen lesz újra javítani.
• Helytelen verziócímke — a hotfix-nek javítási növekményt kell kapnia (v2.3.0 → v2.3.1), nem minor (v2.4.0) vagy major (v3.0.0) értéket. A szemantikus verziózás megsértése megzavarja a build rendszert és összezavarja a felhasználókat.
• CI-ellenőrzések hiánya — még a sürgős hotfix-nek is át kell mennie az automatikus teszteken. A CI kihagyása növeli az új hiba bevezetésének kockázatát. Javasolt külön pipeline-t létrehozni a hotfix ágak számára gyorsított ellenőrzésekkel.

E hibák mindegyike a javítás kiadásának késlekedéséhez vagy új problémák megjelenéséhez vezet az éles környezetben. A csapatoknak rögzíteniük kell a hotfix-szel való munka szabályait a CONTRIBUTING.md-ben, és automatizálniuk kell azokat CI/CD-ellenőrzéseken keresztül.