Hotfix Branch: wat het is, hoe aan te maken en toe te passen in mobiele ontwikkeling

Wat is Hotfix Branch?

Hotfix Branch — is een tijdelijke branch in Git, die wordt aangemaakt voor het operationeel repareren van kritieke defecten in de actieve productie. In tegenstelling tot feature-branches, die van develop aftakken en enkele dagen of weken leven, wordt hotfix vanaf main/master aangemaakt en bestaat precies zo lang als nodig is om de bug te repareren.

De belangrijkste taak van hotfix — het minimaliseren van de tijd tussen het detecteren van een kritieke fout en de reparatie ervan in productie. Het team wacht niet op het einde van de huidige sprint of releasecyclus, maar brengt direct een patch uit. Dit is vooral belangrijk voor mobiele applicaties, waar een kritieke bug gebruikers kan blokkeren en tot verlies van gebruikers kan leiden.

Volgens gegevens van Google Play Console is de gemiddelde moderatietijd van een update in Google Play 2 tot 24 uur. Voor App Store kan een spoedreview 1 tot 4 uur duren. Hotfix-branches maken het mogelijk om de reparatie al voor het einde van de moderatie voor te bereiden en direct na goedkeuring uit te rollen.

Werkingsprincipe van Hotfix

Het hotfix-proces bestaat uit drie stappen: branch aanmaken vanaf main, reparatie uitvoeren en terugmergen naar main en develop. Het belangrijkste verschil met een gewone fix — hotfix wordt altijd in beide branches gemerged, zodat de reparatie niet verloren gaat bij de volgende release.

Het team mag aan hotfix geen nieuwe functionaliteit of refactoring toevoegen. Alleen een puntfix, minimaal noodzakelijk om het kritieke probleem op te lossen. Elke afwijking van deze regel verhoogt het risico op regressie en vertraagt de uitgave van de patch.

Wanneer is Hotfix nodig

Hotfix is nodig in drie scenario's: een kritieke bug blokkeert gebruikers (crash, gegevensverlies), een beveiligingskwetsbaarheid vereist onmiddellijke sluiting, of de kritieke bedrijfslogica is kapot (betalingen, authenticatie). Als de bug niet kritiek is — kan deze worden gerepareerd binnen de normale releasecyclus via develop.

Voor mobiele applicaties kan hotfix ook serverwijzigingen omvatten, als de architectuur het mogelijk maakt om functies op afstand te schakelen (feature flags). In dat geval kan de hotfix-branch minimaal zijn of helemaal niet nodig zijn, als de reparatie aan de serverzijde wordt uitgevoerd.

Branching modellen en plaats van Hotfix

Niet alle branching modellen ondersteunen hotfix-branches. Traditionele Git Flow voorziet hotfix als een volwaardig type branch, terwijl modernere benaderingen (GitHub Flow, Trunk-based) het probleem van spoedreparaties anders oplossen.

Git Flow en Hotfix

Git Flow — is het enige model waarin hotfix een ingebouwd type branch is naast feature en release. In Git Flow wordt hotfix vanaf main aangemaakt en na voltooiing zowel in main (met een versietag) als in develop gemerged. Dit garandeert dat de reparatie niet verloren gaat in de volgende release.

GitHub Flow en Trunk-based

GitHub Flow gebruikt geen apart type branch voor hotfix. In plaats daarvan maakt de ontwikkelaar een gewone feature-branch vanaf main, voert de reparatie uit en opent een Pull Request. Na review en CI-checks wordt de branch in main gemerged en direct uitgerold. Voordeel — eenvoud, nadeel — het ontbreken van een apart kanaal voor spoedreparaties.

Trunk-based ontwikkeling lost het hotfix-probleem op via directe commits naar main (voor kritieke gevallen) met verplichte post-factum review. Deze aanpak vereist een hoge teamdiscipline en betrouwbare geautomatiseerde tests, omdat wijzigingen direct in productie terechtkomen.

Hotfix Branch aanmaken

Hotfix aanmaken begint met het overschakelen naar de hoofdbranch en het aanmaken van een nieuwe branch met het voorvoegsel hotfix/. Laten we het stapsgewijze proces bekijken aan de hand van een voorbeeld van het repareren van een kritieke bug in een mobiele applicatie.

Branch aanmaken vanaf main

Eerste stap — schakel over naar main en zorg ervoor dat de branch actueel is. Maak vervolgens een hotfix-branch aan met een duidelijke naam die de essentie van de reparatie weerspiegelt.

# Schakel over naar main en haal de laatste wijzigingen op
git checkout main
git pull origin main

# Maak een hotfix-branch aan
git checkout -b hotfix/crash-on-login

Na het aanmaken van de branch kan de reparatie worden uitgevoerd. Belangrijk: hotfix moet een minimaal aantal wijzigingen bevatten. Voer geen refactoring uit of voeg geen nieuwe functionaliteiten toe — alleen een puntfix die het probleem oplost.

Reparatie vastleggen

Commit in hotfix moet een informatieve boodschap hebben die het probleem en de oplossing ondubbelzinnig beschrijft. Formaat: type(gebied): korte beschrijving + link naar de taak in de tracker.

# Voeg gewijzigde bestanden toe
git add src/ui/login/LoginActivity.kt

# Maak een commit met beschrijving
git commit -m "fix(login): handle null intent on activity resume

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

De commitboodschap moet een beschrijving van het probleem en een link naar de taak bevatten. Dit vereenvoudigt het zoeken in de geschiedenis en helpt collega's begrijpen wat er is gerepareerd en waarom. Voor mobiele projecten wordt ook de versie van de applicatie vermeld waarin de bug is gevonden.

Mergen naar main en develop

Laatste stap — merge hotfix terug naar main (met een tag van de nieuwe patchversie) en naar develop (zodat de reparatie behouden blijft in de volgende release). Eerst wordt de merge naar main met een tag gemaakt, daarna de merge naar develop.

# Merge naar main en maak een tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Merge naar develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Stuur wijzigingen naar de server
git push origin main --tags
git push origin develop

De vlag --no-ff garandeert het aanmaken van een merge-commit, zelfs als hotfix via fast-forward kon worden toegepast. Dit bewaart de informatie dat er een spoedreparatie is uitgevoerd en vereenvoudigt de analyse van de geschiedenis in de toekomst.

Verschil tussen Hotfix en Feature en Release

Hotfix verschilt fundamenteel van feature- en release-branches in doel, levensduur en mergeregels. Inzicht in deze verschillen is cruciaal voor de juiste organisatie van Git-processen in het team.

Feature-branch is bedoeld voor nieuwe functionaliteit. Het leeft van enkele dagen tot enkele weken, wordt aangemaakt vanaf develop en terug gemerged naar develop. Feature kan veel commits bevatten, waaronder experimentele, die later worden samengeperst via squash of rebase.

Release-branch bereidt de release voor publicatie voor. Het wordt aangemaakt vanaf develop, daarin worden bugs gerepareerd die tijdens de stabilisatie zijn gevonden en het accepteert geen nieuwe functionaliteit. Na voltooiing wordt release gemerged naar main (met tag) en develop.

Hotfix wordt daarentegen direct vanaf main aangemaakt en gemerged, waarbij develop wordt overgeslagen (hoewel het na reparatie ook met develop wordt gesynchroniseerd). Het bevat een minimaal aantal wijzigingen en bestaat een minimale tijd. Als feature of release kunnen worden uitgesteld tot de volgende cyclus, hotfix — niet.

Voor mobiele ontwikkeling is dit onderscheid bijzonder belangrijk: App Store en Google Play staan het uitbrengen van patchversies apart van hoofdreleases toe. Hotfix-branch zorgt voor een proces waarbij de patchrelease niet vermengd raakt met onvoltooide functies.

Typische fouten bij het werken met Hotfix

Fouten bij het werken met hotfix kunnen de voordelen van een spoedreparatie tenietdoen. Laten we vijf veelvoorkomende problemen bekijken die optreden in teams die Git Flow gebruiken.

• Hotfix aanmaken vanaf develop — als hotfix vanaf develop wordt aangemaakt, kunnen onvoltooide functies in de patch terechtkomen. Hotfix mag alleen vanaf main worden aangemaakt om te garanderen dat de reparatie alleen stabiele code bevat.
• Meerdere reparaties in één hotfix — elke reparatie moet in een aparte hotfix-branch zitten. Het mengen van meerdere bugs in één branch bemoeilijkt code review, verhoogt het risico op regressie en bemoeilijkt terugdraaien indien nodig.
• Ontbreken van merge naar develop — als hotfix niet naar develop wordt gemerged, gaat de reparatie verloren bij de volgende release. Het team zal ontdekken dat dezelfde bug opnieuw verschijnt en zal deze opnieuw moeten repareren.
• Onjuiste versietag — hotfix moet een patch-increment krijgen (v2.3.0 → v2.3.1), niet minor (v2.4.0) of major (v3.0.0). Overtreding van semantische versionering verstoort het buildsysteem en verwart gebruikers.
• Ontbreken van CI-checks — zelfs een spoed-hotfix moet geautomatiseerde tests doorstaan. Het overslaan van CI verhoogt het risico op het introduceren van een nieuwe fout. Het wordt aanbevolen om een aparte pipeline voor hotfix-branches te hebben met versnelde controles.

Elk van deze fouten leidt tot vertraging van de patchrelease of tot het ontstaan van nieuwe problemen in productie. Teams moeten de regels voor het werken met hotfix vastleggen in CONTRIBUTING.md en deze automatiseren via CI/CD-checks.