Hotfix Branch: vad det är, hur man skapar och tillämpar i mobil utveckling

Vad är Hotfix Branch?

Hotfix Branch — är en tillfällig gren i Git, som skapas för operativ korrigering av kritiska defekter i aktiv produktion. Till skillnad från feature-grenar, som förgrenar sig från develop och lever flera dagar eller veckor, skapas hotfix från main/master och existerar exakt så länge som behövs för att korrigera buggen.

Huvuduppgiften för hotfix — minimera tiden mellan upptäckt av ett kritiskt fel och dess korrigering i produktion. Teamet väntar inte på att den aktuella sprinten eller releasecykeln ska slutföras, utan släpper en patch omedelbart. Detta är särskilt viktigt för mobilapplikationer, där en kritisk bugg kan blockera användare och leda till användarförlust.

Enligt data från Google Play Console är den genomsnittliga modereringstiden för en uppdatering i Google Play 2 till 24 timmar. För App Store kan en expressgranskning ta 1 till 4 timmar. Hotfix-grenar gör det möjligt att förbereda korrigeringen redan innan modereringen är klar och lansera den omedelbart efter godkännande.

Hur Hotfix fungerar

Hotfix-processen består av tre steg: skapa gren från main, utföra korrigering och sammanfoga tillbaka till main och develop. Den viktigaste skillnaden från en vanlig korrigering — hotfix slås alltid samman med båda grenarna, så att korrigeringen inte går förlorad vid nästa release.

Teamet bör inte lägga till ny funktionalitet eller refaktorisering i hotfix. Endast punktkorrigering, minimalt nödvändig för att eliminera det kritiska problemet. Varje avvikelse från denna regel ökar risken för regression och förlänger tiden för patch-utgåvan.

När behövs Hotfix

Hotfix behövs i tre scenarier: kritisk bugg blockerar användare (krasch, dataförlust), säkerhetslucka kräver omedelbar stängning eller kritisk affärslogik är trasig (betalningar, autentisering). Om buggen inte är kritisk — kan den korrigeras inom ramen för den vanliga releasecykeln via develop.

För mobilapplikationer kan hotfix även omfatta serverändringar, om arkitekturen tillåter fjärrväxling av funktioner (feature flags). I så fall kan hotfix-grenen vara minimal eller inte behövas alls, om korrigeringen görs på serversidan.

Förgreningsmodeller och Hotfix plats

Alla förgreningsmodeller stöder inte hotfix-grenar. Traditionell Git Flow förutser hotfix som en fullvärdig gren typ, medan mer moderna angreppssätt (GitHub Flow, Trunk-based) löser problemet med akuta korrigeringar annorlunda.

Git Flow och Hotfix

Git Flow — är den enda modellen där hotfix är en inbyggd gren typ vid sidan av feature och release. I Git Flow skapas hotfix från main, och efter slutförande slås den samman både med main (med versionstagg) och develop. Detta garanterar att korrigeringen inte går förlorad i nästa release.

GitHub Flow och Trunk-based

GitHub Flow använder inte en separat gren typ för hotfix. Istället skapar utvecklaren en vanlig feature-gren från main, utför korrigeringen och öppnar en Pull Request. Efter granskning och CI-kontroller slås grenen samman med main och lanseras omedelbart. Fördel — enkelhet, nackdel — avsaknad av separat kanal för brådskande korrigeringar.

Trunk-based utveckling löser hotfix-problemet genom direkta commits till main (för kritiska fall) med obligatorisk granskning i efterhand. Detta angreppssätt kräver hög teamdisciplin och pålitliga automatiska tester, eftersom ändringar hamnar i produktion omedelbart.

Hur man skapar Hotfix Branch

Skapa hotfix börjar med att växla till huvudgrenen och skapa en ny gren med prefixet hotfix/. Låt oss gå igenom processen steg för steg med exemplet att korrigera en kritisk bugg i en mobilapplikation.

Skapa gren från main

Första steget — växla till main och försäkra dig om att grenen är aktuell. Skapa sedan en hotfix-gren med ett tydligt namn som återspeglar korrigeringens innebörd.

# Växla till main och hämta de senaste ändringarna
git checkout main
git pull origin main

# Skapa en hotfix-gren
git checkout -b hotfix/crash-on-login

Efter att grenen skapats kan korrigeringen utföras. Viktigt: hotfix bör innehålla ett minimalt antal ändringar. Refaktorisera inte koden och lägg inte till nya funktioner — endast punktkorrigering som eliminerar problemet.

Registrera korrigeringen

Commit i hotfix bör ha ett informativt meddelande som entydigt beskriver problemet och dess lösning. Format: typ(område): kort beskrivning + länk till uppgiften i trackern.

# Lägg till ändrade filer
git add src/ui/login/LoginActivity.kt

# Skapa en commit med beskrivning
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-meddelandet bör innehålla problembeskrivning och länk till uppgiften. Detta förenklar sökning i historiken och hjälper kollegor att förstå vad som korrigerades och varför. För mobilprojekt anges vanligtvis även den applikationsversion där buggen upptäcktes.

Sammanfoga med main och develop

Sista steget — sammanfoga hotfix tillbaka till main (med tagg för den nya patch-versionen) och till develop (så att korrigeringen bevaras i nästa release). Först skapas sammanfogningen till main med tagg, därefter sammanfogningen till develop.

# Sammanfoga med main och skapa en tagg
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Sammanfoga med develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Skicka ändringarna till servern
git push origin main --tags
git push origin develop

Flaggan --no-ff garanterar skapandet av en sammanfogningscommit, även om hotfix kunde tillämpas genom fast-forward. Detta bevarar informationen om att en akut korrigering utfördes och förenklar analysen av historiken i framtiden.

Skillnad mellan Hotfix och Feature och Release

Hotfix skiljer sig fundamentalt från feature- och release-grenar i syfte, livslängd och sammanfogningsregler. Förståelse av dessa skillnader är avgörande för korrekt organisering av Git-processer i teamet.

Feature-gren är avsedd för ny funktionalitet. Den lever från några dagar till några veckor, skapas från develop och sammanfogas tillbaka till develop. Feature kan innehålla många commits, inklusive experimentella, som senare komprimeras genom squash eller rebase.

Release-gren förbereder release för publicering. Den skapas från develop, i den korrigeras buggar som hittats under stabilisering och den tar inte emot ny funktionalitet. Efter slutförande sammanfogas release med main (med tagg) och develop.

Hotfix däremot skapas och sammanfogas direkt med main, förbi develop (även om den efter korrigering synkroniseras med develop också). Den innehåller ett minimalt antal ändringar och existerar under minimal tid. Om feature eller release kan skjutas upp till nästa cykel, hotfix — kan inte.

För mobil utveckling är denna skillnad särskilt viktig: App Store och Google Play tillåter att patch-versioner släpps separat från huvudreleaser. Hotfix-grenen säkerställer en process där patch-releasen inte blandas med ofärdiga funktioner.

Typiska misstag vid arbete med Hotfix

Misstag vid arbete med hotfix kan upphäva fördelarna med akut korrigering. Låt oss titta på fem vanliga problem som uppstår i team som använder Git Flow.

• Skapa hotfix från develop — om hotfix skapas från develop kan ofärdiga funktioner hamna i patchen. Hotfix bör endast skapas från main för att garantera att korrigeringen endast innehåller stabil kod.
• Flera korrigeringar i en hotfix — varje korrigering bör vara i en separat hotfix-gren. Blandning av flera buggar i en gren försvårar kodgranskning, ökar risken för regression och försvårar återställning vid behov.
• Utelämna sammanfogning till develop — om hotfix inte sammanfogas till develop kommer korrigeringen att gå förlorad vid nästa release. Teamet upptäcker att samma bugg har dykt upp igen och tvingas korrigera den på nytt.
• Felaktig versionstagg — hotfix bör få en patch-ökning (v2.3.0 → v2.3.1), inte minor (v2.4.0) eller major (v3.0.0). Brott mot semantisk versionshantering stör byggsystemet och förvirrar användare.
• Brist på CI-kontroller — även en akut hotfix bör gå igenom automatiska tester. Att hoppa över CI ökar risken för att införa ett nytt fel. Det rekommenderas att ha en separat pipeline för hotfix-grenar med snabbare kontroller.

Vart och ett av dessa misstag leder till försening av patch-utgåvan eller till uppkomst av nya problem i produktion. Team bör fastställa regler för arbete med hotfix i CONTRIBUTING.md och automatisera dem genom CI/CD-kontroller.