Hotfix Branch: come crearlo e utilizzarlo nello sviluppo mobile

Cos'è un Hotfix Branch?

Hotfix Branch è un branch temporaneo in Git creato per correggere rapidamente difetti critici in un ambiente di produzione attivo. A differenza dei branch feature, che si diramano da develop e vivono per diversi giorni o settimane, un hotfix viene creato da main/master ed esiste esattamente per il tempo necessario a correggere il bug.

L'obiettivo principale di un hotfix è minimizzare il tempo tra la scoperta di un errore critico e la sua correzione in produzione. Il team non attende la fine dello sprint corrente o del ciclo di rilascio, ma pubblica una patch immediatamente. Questo è particolarmente importante per le applicazioni mobili, dove un bug critico può bloccare gli utenti e portare all'abbandono.

Secondo Google Play Console, il tempo medio di revisione di un aggiornamento in Google Play va da 2 a 24 ore. Per l'App Store, la revisione espressa può richiedere da 1 a 4 ore. I branch hotfix consentono di preparare la correzione prima che la moderazione sia completata e di pubblicarla immediatamente dopo l'approvazione.

Come funziona un Hotfix

Il processo di hotfix consiste in tre passaggi: creare un branch da main, effettuare la correzione e unire di nuovo in main e develop. La differenza fondamentale rispetto a una correzione normale è che un hotfix viene sempre unito in entrambi i branch, in modo che la correzione non venga persa nel rilascio successivo.

Il team non deve introdurre nuove funzionalità o refactoring in un hotfix. Solo una correzione mirata, minimamente necessaria per risolvere il problema critico. Qualsiasi deviazione da questa regola aumenta il rischio di regressione e ritarda la pubblicazione della patch.

Quando è necessario un Hotfix

Un hotfix è necessario in tre scenari: un bug critico blocca gli utenti (crash, perdita di dati), una vulnerabilità di sicurezza richiede una chiusura immediata, o la logica di business critica è danneggiata (pagamenti, autenticazione). Se il bug non è critico, può essere corretto nel normale ciclo di rilascio tramite develop.

Per le applicazioni mobili, un hotfix può includere anche modifiche lato server se l'architettura consente l'attivazione remota delle funzionalità (feature flags). In questo caso, il branch hotfix può essere minimo o non necessario se la correzione può essere effettuata lato server.

Modelli di branching e posizione dell'Hotfix

Non tutti i modelli di branching supportano i branch hotfix. Il Git Flow tradizionale include l'hotfix come tipo di branch a tutti gli effetti, mentre gli approcci più moderni (GitHub Flow, Trunk-based) gestiscono le correzioni urgenti in modo diverso.

Git Flow e Hotfix

Git Flow è l'unico modello in cui l'hotfix è un tipo di branch integrato insieme a feature e release. In Git Flow, un hotfix viene creato da main e, al completamento, viene unito sia in main (con un tag di versione) che in develop. Questo garantisce che la correzione non venga persa nel rilascio successivo.

GitHub Flow e Trunk-based

GitHub Flow non utilizza un tipo di branch separato per gli hotfix. Invece, lo sviluppatore crea un branch feature normale da main, effettua la correzione e apre una Pull Request. Dopo la revisione e i controlli CI, il branch viene unito in main e distribuito immediatamente. Il vantaggio è la semplicità, lo svantaggio è l'assenza di un canale dedicato per le correzioni urgenti.

Lo sviluppo Trunk-based gestisce gli hotfix tramite commit diretti in main (per i casi critici) con revisione obbligatoria successiva. Questo approccio richiede un'elevata disciplina del team e test automatizzati affidabili, poiché le modifiche vanno in produzione istantaneamente.

Come creare un Hotfix Branch

Creare un hotfix inizia passando al branch principale e creando un nuovo branch con il prefisso hotfix/. Esaminiamo il processo passo dopo passo con l'esempio della correzione di un bug critico in un'applicazione mobile.

Creare un branch da main

Primo passo — passare a main e assicurarsi che il branch sia aggiornato. Quindi creare un branch hotfix con un nome chiaro che rifletta la natura della correzione.

# Passare a main e ottenere le ultime modifiche
git checkout main
git pull origin main

# Creare un branch hotfix
git checkout -b hotfix/crash-on-login

Dopo aver creato il branch, è possibile effettuare la correzione. È importante ricordare: un hotfix deve contenere un numero minimo di modifiche. Non rifattorizzare il codice né aggiungere nuove funzionalità — solo la correzione mirata che risolve il problema.

Confermare la correzione

Il commit in un hotfix deve avere un messaggio informativo che descriva chiaramente il problema e la sua soluzione. Formato: tipo(ambito): descrizione breve + link al task nel tracker.

# Aggiungere i file modificati
git add src/ui/login/LoginActivity.kt

# Creare un commit con descrizione
git commit -m "fix(login): handle null intent on activity resume

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

Il messaggio di commit deve contenere una descrizione del problema e un link al task. Questo semplifica la ricerca nella cronologia e aiuta i colleghi a capire cosa è stato corretto e perché. Per i progetti mobili, è anche comune includere la versione dell'applicazione in cui è stato trovato il bug.

Unione in main e develop

Il passaggio finale è unire l'hotfix di nuovo in main (con un tag di nuova versione patch) e in develop (in modo che la correzione sia preservata nel prossimo rilascio). Prima unire in main con un tag, poi unire in develop.

# Unire in main e creare un tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Unire in develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Inviare le modifiche al server
git push origin main --tags
git push origin develop

Il flag --no-ff garantisce la creazione di un commit di unione, anche se l'hotfix avrebbe potuto essere applicato tramite fast-forward. Questo preserva l'informazione che è stata effettuata una correzione d'emergenza e semplifica l'analisi della cronologia in futuro.

Differenza tra Hotfix, Feature e Release

Un hotfix è fondamentalmente diverso dai branch feature e release per scopo, durata e regole di unione. Comprendere queste differenze è fondamentale per organizzare correttamente i processi Git in un team.

Un branch feature è destinato a nuove funzionalità. Vive da diversi giorni a diverse settimane, viene creato da develop e unito di nuovo in develop. Una feature può contenere molti commit, inclusi quelli sperimentali, che vengono successivamente compressi tramite squash o rebase.

Un branch release prepara un rilascio per la distribuzione. Viene creato da develop, in esso vengono corretti i bug trovati durante la stabilizzazione e non accetta nuove funzionalità. Al completamento, il release viene unito in main (con tag) e develop.

Un hotfix, d'altra parte, viene creato e unito direttamente con main, bypassando develop (sebbene dopo la correzione venga sincronizzato anche con develop). Contiene un numero minimo di modifiche ed esiste per un tempo minimo. Mentre i branch feature o release possono essere rimandati al ciclo successivo, un hotfix non può.

Per lo sviluppo mobile, questa distinzione è particolarmente importante: l'App Store e Google Play consentono di pubblicare versioni patch separatamente dai rilasci principali. Il branch hotfix garantisce che un rilascio patch non venga mescolato con funzionalità non completate.

Errori tipici quando si lavora con Hotfix

Errori quando si lavora con gli hotfix possono annullare i vantaggi della correzione d'emergenza. Esaminiamo i cinque problemi più comuni che sorgono nei team che utilizzano Git Flow.

• Creare un hotfix da develop — se un hotfix viene creato da develop, funzionalità non completate possono finire nella patch. Un hotfix dovrebbe essere creato solo da main per garantire che solo codice stabile sia incluso nella correzione.
• Più correzioni in un unico hotfix — ogni correzione dovrebbe essere nel proprio branch hotfix. Mescolare più bug in un unico branch complica la revisione del codice, aumenta il rischio di regressione e rende difficile il rollback se necessario.
• Saltare l'unione in develop — se un hotfix non viene unito in develop, la correzione andrà persa nel prossimo rilascio. Il team scoprirà che lo stesso bug è riapparso e dovrà correggerlo di nuovo.
• Tag di versione errato — un hotfix dovrebbe ricevere un incremento di patch (v2.3.0 → v2.3.1), non un incremento minore (v2.4.0) o maggiore (v3.0.0). Violare il versionamento semantico rompe il sistema di build e confonde gli utenti.
• Mancanza di controlli CI — anche un hotfix d'emergenza deve superare i test automatizzati. Saltare il CI aumenta il rischio di introdurre un nuovo errore. Si consiglia di avere una pipeline separata per i branch hotfix con controlli accelerati.

Ciascuno di questi errori porta a un ritardo nella pubblicazione della patch o alla comparsa di nuovi problemi in produzione. I team dovrebbero documentare le regole di lavoro con gli hotfix in CONTRIBUTING.md e automatizzarle attraverso i controlli CI/CD.