Hotfix Branch : définition, création et utilisation dans le développement mobile

Qu'est-ce qu'un Hotfix Branch ?

Hotfix Branch est une branche temporaire dans Git créée pour corriger rapidement des défauts critiques dans un environnement de production actif. Contrairement aux branches feature, qui bifurquent depuis develop et vivent plusieurs jours ou semaines, un hotfix est créé à partir de main/master et existe exactement le temps nécessaire pour corriger le bug.

L'objectif principal d'un hotfix est de minimiser le temps entre la découverte d'une erreur critique et sa correction en production. L'équipe n'attend pas la fin du sprint actuel ou du cycle de publication, elle publie un correctif immédiatement. C'est particulièrement important pour les applications mobiles, où un bug critique peut bloquer les utilisateurs et entraîner une fuite.

Selon la Google Play Console, le temps moyen de révision d'une mise à jour dans Google Play est de 2 à 24 heures. Pour l'App Store, la révision express peut prendre de 1 à 4 heures. Les branches hotfix permettent de préparer la correction avant la fin de la modération et de la publier immédiatement après approbation.

Fonctionnement du Hotfix

Le processus de hotfix comprend trois étapes : créer une branche à partir de main, effectuer la correction et fusionner dans main et develop. La différence clé avec une correction normale est qu'un hotfix est toujours fusionné dans les deux branches, afin que la correction ne soit pas perdue lors de la prochaine publication.

L'équipe ne doit introduire aucune nouvelle fonctionnalité ni refactorisation dans un hotfix. Seulement une correction ciblée, minimalement nécessaire pour résoudre le problème critique. Tout écart à cette règle augmente le risque de régression et retarde la publication du correctif.

Quand un Hotfix est nécessaire

Un hotfix est nécessaire dans trois scénarios : un bug critique bloque les utilisateurs (plantage, perte de données), une vulnérabilité de sécurité nécessite une fermeture immédiate, ou la logique métier critique est cassée (paiements, authentification). Si le bug n'est pas critique, il peut être corrigé dans le cycle de publication normal via develop.

Pour les applications mobiles, un hotfix peut également inclure des modifications côté serveur si l'architecture permet le basculement à distance de fonctionnalités (feature flags). Dans ce cas, la branche hotfix peut être minimale ou même inutile si la correction peut être effectuée côté serveur.

Modèles de branchement et place du Hotfix

Tous les modèles de branchement ne supportent pas les branches hotfix. Le Git Flow traditionnel inclut le hotfix comme un type de branche à part entière, tandis que les approches plus modernes (GitHub Flow, Trunk-based) gèrent les corrections d'urgence différemment.

Git Flow et Hotfix

Git Flow est le seul modèle où le hotfix est un type de branche intégré au même titre que feature et release. Dans Git Flow, un hotfix est créé à partir de main et, à son terme, est fusionné à la fois dans main (avec un tag de version) et dans develop. Cela garantit que la correction n'est pas perdue dans la prochaine publication.

GitHub Flow et Trunk-based

GitHub Flow n'utilise pas de type de branche séparé pour les hotfix. Au lieu de cela, le développeur crée une branche feature normale à partir de main, effectue la correction et ouvre une Pull Request. Après révision et vérifications CI, la branche est fusionnée dans main et déployée immédiatement. L'avantage est la simplicité, l'inconvénient est l'absence de canal dédié pour les corrections urgentes.

Le développement Trunk-based gère les hotfix par des commits directs dans main (pour les cas critiques) avec révision obligatoire a posteriori. Cette approche nécessite une discipline d'équipe élevée et des tests automatisés fiables, car les modifications arrivent en production instantanément.

Comment créer un Hotfix Branch

Créer un hotfix commence par basculer sur la branche principale et créer une nouvelle branche avec le préfixe hotfix/. Examinons le processus pas à pas avec l'exemple de la correction d'un bug critique dans une application mobile.

Créer une branche à partir de main

Première étape — basculer sur main et s'assurer que la branche est à jour. Ensuite, créer une branche hotfix avec un nom clair reflétant la nature de la correction.

# Basculer sur main et obtenir les dernières modifications
git checkout main
git pull origin main

# Créer une branche hotfix
git checkout -b hotfix/crash-on-login

Après avoir créé la branche, vous pouvez effectuer la correction. Il est important de se rappeler : un hotfix doit contenir un nombre minimal de modifications. Ne refactorisez pas le code et n'ajoutez pas de nouvelles fonctionnalités — seulement la correction ciblée qui résout le problème.

Valider la correction

Le commit dans un hotfix doit avoir un message informatif décrivant clairement le problème et sa solution. Format : type(domaine) : description brève + lien vers la tâche dans le tracker.

# Ajouter les fichiers modifiés
git add src/ui/login/LoginActivity.kt

# Créer un commit avec description
git commit -m "fix(login): handle null intent on activity resume

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

Le message de commit doit contenir une description du problème et un lien vers la tâche. Cela simplifie la recherche dans l'historique et aide les collègues à comprendre ce qui a été corrigé et pourquoi. Pour les projets mobiles, il est également courant d'indiquer la version de l'application où le bug a été trouvé.

Fusion dans main et develop

La dernière étape consiste à fusionner le hotfix de retour dans main (avec un tag de nouvelle version de correctif) et dans develop (pour que la correction soit préservée dans la prochaine publication). D'abord, fusionner dans main avec un tag, puis fusionner dans develop.

# Fusionner dans main et créer un tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Fusionner dans develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Pousser les modifications vers le serveur
git push origin main --tags
git push origin develop

Le drapeau --no-ff garantit la création d'un commit de fusion, même si le hotfix aurait pu être appliqué via fast-forward. Cela préserve l'information qu'une correction d'urgence a été effectuée et simplifie l'analyse de l'historique à l'avenir.

Différence entre Hotfix, Feature et Release

Un hotfix diffère fondamentalement des branches feature et release en termes d'objectif, de durée de vie et de règles de fusion. Comprendre ces différences est essentiel pour organiser correctement les processus Git dans une équipe.

Une branche feature est destinée à une nouvelle fonctionnalité. Elle vit de plusieurs jours à plusieurs semaines, est créée à partir de develop et fusionnée dans develop. Une feature peut contenir plusieurs commits, y compris expérimentaux, qui sont ensuite compressés via squash ou rebase.

Une branche release prépare une publication pour le déploiement. Elle est créée à partir de develop, les bugs trouvés lors de la stabilisation y sont corrigés, et elle n'accepte pas de nouvelle fonctionnalité. Une fois terminée, la release est fusionnée dans main (avec tag) et develop.

Un hotfix, en revanche, est créé et fusionné directement avec main, contournant develop (bien qu'après la correction, il soit également synchronisé avec develop). Il contient un nombre minimal de modifications et existe pendant un temps minimal. Alors que les branches feature ou release peuvent être reportées au prochain cycle, un hotfix ne le peut pas.

Pour le développement mobile, cette distinction est particulièrement importante : l'App Store et Google Play permettent de publier des versions de correctif séparément des publications principales. La branche hotfix garantit qu'une publication de correctif n'est pas mélangée à des fonctionnalités inachevées.

Erreurs typiques lors du travail avec Hotfix

Les erreurs lors du travail avec les hotfix peuvent annuler les avantages de la correction d'urgence. Examinons les cinq problèmes les plus courants qui surviennent dans les équipes utilisant Git Flow.

• Créer un hotfix à partir de develop — si un hotfix est créé à partir de develop, des fonctionnalités inachevées peuvent se retrouver dans le correctif. Un hotfix doit être créé uniquement à partir de main pour garantir que seul du code stable est inclus dans la correction.
• Plusieurs corrections dans un même hotfix — chaque correction doit être dans sa propre branche hotfix. Mélanger plusieurs bugs dans une même branche complexifie la révision de code, augmente le risque de régression et rend le rollback difficile si nécessaire.
• Sauter la fusion dans develop — si un hotfix n'est pas fusionné dans develop, la correction sera perdue lors de la prochaine publication. L'équipe découvrira que le même bug est réapparu et devra le corriger à nouveau.
• Tag de version incorrect — un hotfix doit recevoir un incrément de correctif (v2.3.0 → v2.3.1), pas un mineur (v2.4.0) ou un majeur (v3.0.0). La violation du versionnage sémantique casse le système de build et perturbe les utilisateurs.
• Absence de vérifications CI — même un hotfix urgent doit passer les tests automatisés. Sauter le CI augmente le risque d'introduire une nouvelle erreur. Il est recommandé d'avoir un pipeline séparé pour les branches hotfix avec des vérifications accélérées.

Chacune de ces erreurs entraîne un retard dans la publication du correctif ou l'apparition de nouveaux problèmes en production. Les équipes doivent documenter les règles de travail avec les hotfix dans CONTRIBUTING.md et les automatiser via des vérifications CI/CD.