Les branches : travailler en parallèle

🎯 Objectif : À la fin de ce chapitre, tu sauras créer des branches, naviguer entre elles, fusionner du code et résoudre les conflits sans stress. ⏱️ Durée estimée : 45 minutes | Niveau : Intermédiaire

Tu travailles sur une feature et ton collègue doit corriger un bug urgent en prod. Sans branches, vous seriez bloqués : soit tu abandonnes ton travail en cours, soit le fix attend. Les branches règlent ce problème — chacun travaille sur sa propre ligne de développement, indépendamment.

Ce chapitre t’apprend à maîtriser les branches Git : de la création à la fusion, en passant par la résolution de conflits. C’est la compétence fondamentale pour travailler en équipe.

Pourquoi les branches changent tout

Sans branches, cinq développeurs qui pushent sur le même code en même temps se marchent dessus en permanence. Chaque push risque d’écraser le travail des autres. Le résultat : du stress, des régressions, et des déploiements cassés.

Les branches isolent le travail de chacun. Tu crées ta branche, tu codes ta feature tranquille, et tu réintègres le tout dans la branche principale quand c’est prêt et testé. Si ta feature ne fonctionne pas, tu supprimes la branche — le code principal n’a jamais été touché.

🔥 Cas réel : Dans une équipe e-commerce, un développeur travaille sur le nouveau système de paiement (feature/checkout-v2) pendant que l’équipe support corrige un bug de prix affiché (hotfix/price-display). Les deux avancent en parallèle. Le hotfix est mergé et déployé en 30 minutes. La feature checkout continue son cycle de développement sur 2 semaines. Sans branches, il aurait fallu choisir : corriger le bug OU avancer la feature. Pas les deux.

Comprendre le concept

Une branche Git, techniquement, c’est un pointeur vers un commit. Rien de plus. Créer une branche = créer un fichier de 41 octets contenant un hash. C’est quasi gratuit — contrairement à SVN qui copiait physiquement tout le répertoire.

Imagine ton projet comme une timeline. Chaque commit est un point. Quand tu crées une branche, tu démarres une ligne parallèle qui part de ce point. Tu codes dessus sans impacter la ligne principale (main). Quand c’est prêt, tu fusionnes (merge) les deux lignes.

Git utilise un pointeur spécial appelé HEAD pour savoir sur quelle branche tu te trouves. Quand tu fais un commit, le pointeur de ta branche courante avance. C’est tout le mécanisme.

🧠 À retenir : Branche = pointeur mobile vers un commit. HEAD = pointeur vers la branche active. Créer des branches ne coûte rien — fais-en une par tâche, même petite.

Commandes essentielles

Voici les commandes que tu utiliseras au quotidien pour gérer tes branches. Chaque bloc couvre un aspect du workflow.

Pour voir et créer des branches, git switch -c est la commande moderne qui crée une branche et bascule dessus en une seule opération :

# Lister les branches (l'étoile marque la branche courante)
git branch

# Lister toutes les branches (locales + distantes)
git branch -a

# Créer ET basculer sur une nouvelle branche
git switch -c feature/auth

# Basculer vers une branche existante
git switch main

# Revenir à la branche précédente (comme cd -)
git switch -

💡 Tip DevOps : git switch a remplacé git checkout pour les branches depuis Git 2.23. L’ancienne commande mélangeait changement de branche et restauration de fichiers — source de confusion et d’erreurs. Utilise git switch pour les branches, git restore pour les fichiers.

Pour fusionner une branche, place-toi d’abord sur la branche qui reçoit le code, puis merge la branche source :

# Workflow standard : merge feature dans main
git switch main
git merge feature/auth

# Merge avec commit explicite (même si fast-forward possible)
git merge --no-ff feature/auth -m "Merge feature/auth into main"

# Supprimer la branche après merge (bonne hygiène)
git branch -d feature/auth

⚠️ Attention : Le merge s’exécute depuis la branche cible. Tu te places sur main, puis tu merges feature. Pas l’inverse. Si tu merges main dans ta feature, tu ne fais que synchroniser ta branche — tu n’intègres pas ta feature dans main.

Git gère deux types de fusion. Le fast-forward se produit quand main n’a pas bougé depuis la création de ta branche — Git avance simplement le pointeur, pas de commit de merge. Le three-way merge intervient quand les deux branches ont divergé — Git crée un commit de merge avec deux parents. En équipe, c’est le cas le plus fréquent.

💡 Tip DevOps : Beaucoup d’équipes utilisent --no-ff systématiquement. Le commit de merge crée un repère visible dans l’historique : “ici, la feature X a été intégrée”. Ça simplifie le debugging et permet de revert une feature entière d’un coup.

Pour visualiser l’historique des branches et comprendre la structure du projet :

# Historique graphique compact
git log --oneline --graph --all --decorate

# Créer un alias pour aller plus vite
git config --global alias.lg "log --oneline --graph --all --decorate"
# Ensuite : git lg

Cas concret : workflow en entreprise

En entreprise, les branches suivent des conventions de nommage qui déclenchent des comportements automatisés dans la CI/CD :

• feature/ → nouvelle fonctionnalité → lance les tests unitaires
• fix/ ou hotfix/ → correction de bug → lance tests + déploiement staging
• release/ → préparation de release → tests d’intégration complets

Voici le workflow quotidien typique d’un développeur dans une équipe utilisant le GitHub Flow :

# 1. Créer sa branche depuis main à jour
git switch main
git pull origin main
git switch -c feature/user-api

# 2. Travailler, commiter régulièrement
echo 'def get_users(): return []' > api.py
git add api.py
git commit -m "feat(api): endpoint GET /users"

# 3. Synchroniser avec main régulièrement (réduit les conflits)
git pull origin main

# 4. Pousser sa branche et ouvrir une Pull Request
git push origin feature/user-api
# → Ouvrir la PR sur GitHub/GitLab, demander une review
# → Après validation, merger via l'interface web

# 5. Nettoyer en local
git switch main
git pull origin main
git branch -d feature/user-api

🔥 Cas réel : Ce workflow — branche courte (1-3 jours), Pull Request, code review, merge — est utilisé par la majorité des équipes tech dans le monde. La clé : des branches qui vivent peu longtemps. Une branche de 2 jours produit des conflits mineurs. Une branche de 3 semaines produit un cauchemar de merge.

Pièges fréquents et résolution de conflits

Piège n°1 : changer de branche avec des modifications non committées. Git peut refuser le switch ou, pire, emmener tes modifications sur l’autre branche. Avant de changer de branche, commite ou utilise git stash pour mettre ton travail de côté.

Piège n°2 : supprimer une branche non mergée. git branch -d vérifie que ta branche a été fusionnée. git branch -D (majuscule) force la suppression sans vérification — tes commits deviennent orphelins. Utilise toujours -d sauf si tu sais ce que tu fais.

Piège n°3 : paniquer devant un conflit. Un conflit arrive quand deux branches modifient les mêmes lignes du même fichier. Git ne peut pas deviner quelle version garder — il te demande de choisir. C’est mécanique, pas dramatique.

Quand un conflit survient, Git marque le fichier avec des indicateurs. Voici comment le résoudre :

# Après un merge qui produit un conflit :
# Git affiche → CONFLICT (content): Merge conflict in config.txt

# Le fichier contient des marqueurs :
# <<<<<<< HEAD
# version main
# =======
# version feature
# >>>>>>> feature/update

# 1. Ouvre le fichier, choisis la bonne version, supprime les marqueurs
# 2. Stage et commite
git add config.txt
git commit -m "fix: résolution du conflit sur config.txt"

# Si tu veux tout annuler et revenir à l'état avant le merge :
git merge --abort

⚠️ Attention : Ne tente jamais de résoudre manuellement un conflit dans un fichier généré (package-lock.json, yarn.lock). Accepte une version, puis relance npm install ou yarn install pour régénérer le fichier proprement.

🧠 À retenir : Le meilleur moment pour résoudre un conflit, c’est quand il est petit. Synchronise ta branche avec main tous les jours. Un conflit de 3 lignes se résout en 30 secondes. Un conflit de 300 lignes après 3 semaines de divergence, c’est une heure de souffrance.

Exercice et mémo

Exercice pratique

Reproduis ce workflow complet dans un répertoire de test :

# Setup
mkdir git-branches-lab && cd git-branches-lab
git init && echo "# Lab" > README.md
git add README.md && git commit -m "init"

# Crée une feature branch, ajoute du code, merge dans main
git switch -c feature/hello
echo 'print("Hello Git!")' > hello.py
git add hello.py && git commit -m "feat: add hello script"
git switch main
git merge --no-ff feature/hello -m "Merge feature/hello"
git branch -d feature/hello

# Provoque un conflit volontairement
git switch -c branch-a
echo "version A" > shared.txt
git add shared.txt && git commit -m "version A"
git switch main
echo "version main" > shared.txt
git add shared.txt && git commit -m "version main"
git merge branch-a
# → CONFLIT ! Résous-le, puis :
echo "version combinée" > shared.txt
git add shared.txt && git commit -m "fix: conflit résolu"

# Admire le résultat
git log --oneline --graph --all

Vérifie que tu sais : créer une branche, switcher, merger, et résoudre un conflit manuellement. Si tu maîtrises cet exercice, tu as les bases solides.

📝 À retenir

• Branche = pointeur léger vers un commit — en créer ne coûte rien
• git switch -c crée et bascule en une commande
• git merge fusionne depuis la branche cible (place-toi sur main d’abord)
• Fast-forward = historique linéaire, three-way merge = commit de merge
• Conflits = deux branches modifient les mêmes lignes → résolution manuelle, puis git add + git commit
• Bonne hygiène : branches courtes, sync quotidienne avec main, suppression après merge

🔥 Cas réel : Le pattern dominant en entreprise — branche → Pull Request → code review → merge — s’appelle le GitHub Flow. Simple, efficace, et adopté par la majorité des équipes. Tu le pratiqueras dès le prochain chapitre.

➡️ La suite

Dans le prochain chapitre, on explore rebase vs merge, git stash, cherry-pick et les stratégies de branching professionnelles (Git Flow, Trunk-Based Development). 🚀