Git gud

French

English

French

English

Appearance

Le scénario Support ​

Le plus souvent, c’est simple : vous mergez des features sur main, puis, quand vous êtes prêts, vous tagguez un commit de main en nouvelle release. Et basta. Si cette version est stable, vous la shippez.

Mais parfois…

  • Vous avez besoin d’une longue phase de stabilisation (QA, UAT) sans geler main
  • Un bug critique apparaît un mois plus tard en prod, et vous devez le patcher sans livrer toutes les nouveautés de main
  • Vous aviez gelé main pour une release et… on vous demande d’ajouter « juste » une dernière feature (promis c’est la dernière)

Dans ces cas, la branche support est votre outil le plus précieux. Pas obligatoire à chaque release, mais indispensable quand il le faut : une copie isolée de votre version, où appliquer des correctifs en sécurité.

Convention de nommage : support/

J'utilise volontairement le préfixe support/ pour ces branches. Bien que release/ soit plus courant, je pense qu’il décrit mal le rôle à long terme de la branche. Son objectif est de supporter une version en production, et pas seulement de la publier. Le préfixe support/ reflète mieux le cycle de vie prolongé de la branche et aide à éviter une suppression accidentelle en rendant son but explicite.

Cela dit, si vous préférez release/, faites comme vous le sentez.

Deux scénarios principaux :

  1. Pré‑release : créer support/* pour durcir une version avant lancement
  2. Post‑release : patcher une version déjà en prod via une branche support/*

Un bug critique (GG-21) touche la 1.1.0 en production. Pendant ce temps, 1.2.0 est déjà en chantier sur main.

Objectif : livrer 1.1.1 avec uniquement le correctif de GG-21.

Étape 1 : se placer sur la bonne branche de support ​

bash
git checkout support/1.1
git pull

Vous êtes maintenant dans l’environnement qui reflète exactement le code 1.1.0.

Étape 2 : créer la branche de hotfix ​

Même en urgence, on isole le travail :

bash
git checkout -b hotfix/GG-21_bug-critique-prod

À partir d’ici, c’est le même flux que pour une feature.

Étape 3 : corriger et merger vers support/1.1 ​

Committez avec un fix: clair et ouvrez une PR vers support/1.1 (pas main).

Une fois mergée, support/1.1 contient le code de la future 1.1.1.

Étape 4 : tagguer le hotfix ​

bash
git checkout support/1.1
git pull
git tag -a 1.1.1 -m "Version 1.1.1 : hotfix critique pour GG-21"
git push origin 1.1.1

Vous pouvez déployer 1.1.1. L’incendie est éteint. Presque.

Étape 5 : reporter le fix sur main (ne l’oubliez JAMAIS) ​

Le bug corrigé en prod existe encore sur main. Si vous ne le portez pas, il réapparaîtra à la prochaine version et vous aurez l’air malin.

La méthode propre : git cherry-pick.

bash
git checkout main
git pull
git checkout -b bugfix/GG-21_report-hotfix-vers-main
git cherry-pick <hash-du-commit-de-hotfix>
git push -u origin bugfix/GG-21_report-hotfix-vers-main

Le cherry‑pick applique uniquement le commit de hotfix sur main. Une fois mergé, le bug est corrigé partout.

Et après ? ​

Gardez la branche support/1.1. Ne la supprimez pas : elle resservira (correctifs… ou « petit ajout » de dernière minute 🤫).

Cette branche se comporte comme un nouveau main pour les versions 1.1.x.