Guide complet du branching Git : créer, basculer, supprimer

Le branching Git vous permet de travailler sur une fonctionnalité, une correction ou une expérience sans perturber la ligne de développement principale. Une bonne habitude de branching maintient vos changements organisés et facilite les revues, les tests et les retours en arrière.

Les branches sont des pointeurs légers vers des commits. Cela signifie que les créer, basculer et les supprimer est rapide, mais les choix que vous faites affectent toujours la clarté de l'historique de votre projet.

Ce qu'est une branche Git

Une branche Git est un nom mobile qui pointe vers un commit. Lorsque vous commitez un nouveau travail sur une branche, Git déplace ce nom de branche vers le nouveau commit.

La plupart des projets ont une branche principale telle que main ou master. Les équipes maintiennent généralement cette branche stable, puis créent des branches à courte durée de vie pour un travail spécifique :

git switch -c fix-login-timeout

Ceci crée une nouvelle branche et bascule dessus. Les exemples Git plus anciens peuvent utiliser :

git checkout -b fix-login-timeout

Les deux modèles sont courants, mais git switch est plus facile à lire car il se concentre uniquement sur le mouvement de la branche.

Les noms de branches doivent être suffisamment spécifiques pour expliquer le travail. feature est trop vague. feature/add-health-check-endpoint ou fix/nginx-502-upstream-timeout est bien meilleur. Un nom clair vous aide, vous et vos relecteurs, à comprendre la branche avant d'ouvrir des fichiers.

Créer et basculer des branches

Avant de créer une branche, partez de la bonne base. Pour la plupart des équipes, cela signifie mettre à jour votre branche principale d'abord :

git switch main
git pull
git switch -c feature/add-metrics-endpoint

Cela réduit la probabilité que votre nouvelle branche parte d'un code obsolète. Cela n'élimine pas les conflits, mais vous donne un point de départ plus propre.

Pour lister les branches locales, exécutez :

git branch

La branche courante a un astérisque à côté. Pour voir aussi les branches distantes, utilisez :

git branch -a

Pour basculer vers une branche existante :

git switch nom-de-branche

Si la branche existe uniquement sur le dépôt distant, vous pouvez généralement créer une branche de suivi locale avec :

git switch --track origin/nom-de-branche

Le suivi est important car il connecte votre branche locale à sa contrepartie distante. Une fois le suivi configuré, des commandes simples comme git pull et git push savent quelle branche distante utiliser.

Pour un scénario concret, imaginez que vous devez corriger un échec de pipeline Jenkins tout en travaillant sur un nettoyage plus important d'images Docker. Mettez ces changements sur des branches séparées. La correction urgente peut être revue et fusionnée rapidement, tandis que le nettoyage plus important peut continuer sans la bloquer.

Pour les bases connexes, voir démarrer avec les dépôts Git.

Garder les branches organisées

Les branches deviennent désordonnées lorsqu'elles restent ouvertes trop longtemps ou accumulent des changements sans rapport. La meilleure branche est généralement petite, ciblée et facile à revoir.

Utilisez une branche pour un seul objectif :

• Une branche de correction de bogue doit inclure la correction et tous les tests associés.
• Une branche de fonctionnalité doit inclure la fonctionnalité, pas des refactorisations au passage.
• Une branche de nettoyage doit éviter les changements de comportement sauf s'ils font clairement partie du nettoyage.

Avant de pousser, vérifiez votre travail :

git status
git diff --staged

Cela détecte les fichiers accidentels et les modifications sans rapport. C'est particulièrement utile dans les dépôts DevOps où les fichiers générés, la configuration locale et les modèles de secrets peuvent se trouver près des fichiers source réels.

Lorsque votre branche a besoin des derniers changements de main, vous avez deux options courantes :

git merge main

ou :

git rebase main

Merge préserve l'historique exact de la branche. Rebase réécrit vos commits de branche au-dessus de la dernière base. Les deux sont utiles, mais les équipes doivent se mettre d'accord sur le style attendu avant de fusionner un travail partagé. Si vous n'êtes pas sûr, préférez le workflow documenté par votre projet.

Supprimer des branches en toute sécurité

Supprimer les anciennes branches maintient votre dépôt plus facile à naviguer. Après qu'une branche a été fusionnée, supprimez la copie locale avec :

git branch -d nom-de-branche

Le -d en minuscule est l'option la plus sûre. Git refuse de supprimer la branche s'il estime que le travail n'a pas été fusionné.

Si vous devez vraiment supprimer une branche locale non fusionnée, utilisez :

git branch -D nom-de-branche

Utilisez ceci avec précaution. Cela supprime le nom de la branche même si les commits ne sont pas fusionnés. Les commits peuvent encore être récupérables pendant un certain temps via le reflog, mais vous ne devez pas considérer cela comme un filet de sécurité normal.

Pour supprimer une branche distante :

git push origin --delete nom-de-branche

Ne supprimez les branches distantes que lorsque le travail est fusionné, abandonné ou clairement vous appartient. Dans les équipes partagées, les branches distantes peuvent être utilisées par les revues, les aperçus de déploiement ou d'autres développeurs.

Vous pouvez nettoyer les références de suivi distant obsolètes avec :

git fetch --prune

Cela supprime les références locales aux branches distantes qui n'existent plus sur le serveur. Cela ne supprime pas les vraies branches distantes.

Quand demander à un collègue

La création et le basculement de branches sont des opérations à faible risque. Les moments risqués sont la suppression de travail non fusionné, le force-push et le rebase de branches que d'autres personnes peuvent déjà utiliser.

Demandez avant de faire un force-push sur une branche partagée. Demandez également avant de supprimer une branche distante que vous n'avez pas créée. Dans les dépôts CI/CD lourds, une branche peut déclencher des builds, des aperçus ou des règles de déploiement qui ne sont pas évidents depuis Git seul.

Un bon branching repose principalement sur la clarté. Créez une branche à partir de la bonne base, nommez-la d'après le travail, gardez-la ciblée et supprimez-la lorsqu'elle n'est plus nécessaire. Ces habitudes rendent Git plus facile pour vous et plus sûr pour toute l'équipe.