Branches Git & Merge Requests

Les branches permettent de travailler sur des fonctionnalités ou corrections en isolation, sans perturber le code stable de la branche principale.

Pourquoi des branches ?

Sans branches :
  Tout le monde modifie main → instabilité constante, conflits permanents

Avec branches :
  main (stable, prêt pour la prod)
  ├── feature/login        ← Dev 1 travaille ici
  ├── feature/dashboard    ← Dev 2 travaille ici
  └── bugfix/cart-error    ← Dev 3 travaille ici

→ Chacun isole son travail, main reste stable

Objectif : maintenir une branche main stable, toujours prête pour la production.

La branche principale

• Créée automatiquement à l'initialisation du repo
• Représente la version stable et déployable du projet
• Bonne pratique : ne jamais pousser directement sur main

Commandes de gestion des branches

# Lister les branches locales
git branch

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

# Créer une nouvelle branche
git branch feature/login

# Créer ET basculer sur la nouvelle branche
git checkout -b feature/login
git switch -c feature/login      # Commande moderne (Git 2.23+)

# Basculer sur une branche existante
git checkout main
git switch main                  # Commande moderne

# Supprimer une branche (après merge)
git branch -d feature/login      # Sécurisé (échoue si non mergée)
git branch -D feature/login      # Force la suppression

Cycle de vie d'une branche

1. Partir de main (code stable)
   git checkout main
   git pull
   git checkout -b feature/user-profile

2. Travailler sur la branche
   # modifier des fichiers...
   git add .
   git commit -m "feat: add user profile page"
   git commit -m "feat: add avatar upload"

3. Pousser la branche vers le remote
   git push -u origin feature/user-profile

4. Ouvrir une Merge Request (MR) / Pull Request (PR)
   → Code review par un collègue

5. Merger dans main après approbation
   git checkout main
   git merge feature/user-profile

6. Supprimer la branche (nettoyage)
   git branch -d feature/user-profile

Nomenclature recommandée des branches

feature/nom-de-la-fonctionnalite     → Nouvelle fonctionnalité
bugfix/description-du-bug            → Correction de bug
hotfix/correction-urgente            → Correctif urgent en production
release/v1.2.0                       → Préparation d'une release
chore/mise-a-jour-dependances        → Tâche de maintenance

Exemples concrets :

feature/user-authentication
feature/payment-integration
bugfix/ticket-2134-login-error
bugfix/cart-total-incorrect
hotfix/security-patch-xss
release/v2.1.0

Bonne pratique : 1 branche par fonctionnalité ou bugfix.

git merge — Fusionner des branches

# Se placer sur la branche de destination
git checkout main

# Fusionner la branche source
git merge feature/login

# Merge avec message de commit explicite
git merge --no-ff feature/login -m "Merge feature/login into main"

Types de merge

Fast-forward merge (pas de commit de merge) :
  main:    A ─── B
                  └── C ─── D  (feature)
  Résultat: A ─── B ─── C ─── D

No fast-forward (crée un commit de merge) :
  main:    A ─── B ─────────────── M  (merge commit)
                  └── C ─── D ──┘

Résoudre un conflit de merge

Un conflit survient quand deux branches modifient la même portion de code.

# Git indique les fichiers en conflit
git merge feature/login
# Auto-merging app.js
# CONFLICT (content): Merge conflict in app.js

# Voir les fichiers en conflit
git status

Le fichier en conflit contient des marqueurs :

<<<<<<< HEAD (votre branche actuelle)
const loginUrl = "/api/v2/login"
=======
const loginUrl = "/api/v1/auth/login"
>>>>>>> feature/login (branche à merger)

Résolution :

# 1. Ouvrir le fichier, choisir la bonne version et supprimer les marqueurs
# 2. Stager le fichier résolu
git add app.js

# 3. Finaliser le merge
git commit -m "fix: resolve merge conflict in app.js"

Merge Requests (MR) / Pull Requests (PR)

Une Merge Request (GitLab) ou Pull Request (GitHub) = demande de fusion d'une branche dans une autre, avec revue de code obligatoire.

Développeur                        Reviewer
────────────                       ──────────────
1. Crée la branche feature/xx
2. Développe la fonctionnalité
3. Push sur le remote
4. Ouvre une MR/PR               → Notifié par email/Slack
                                   5. Examine les changements
                                   6. Laisse des commentaires
                                   7. Approuve ✓ ou Refuse ✗
8. Corrige si besoin
9. Merge dans main ──────────────────────────────────►

Ce qu'un reviewer peut voir dans une MR

Différences ligne par ligne :
  - const loginUrl = "/api/v1/auth"    ← ligne supprimée
  + const loginUrl = "/api/v2/auth"    ← ligne ajoutée

Fichiers modifiés : app.js, auth.js, tests/auth.test.js
Commits inclus : 3 commits

Bonne pratique : Toujours faire relire son code par un autre développeur avant de merger dans main. Cela évite les bugs et partage la connaissance.

À retenir

• Branche = espace de travail isolé qui ne perturbe pas main
• git checkout -b feature/xx = créer et basculer sur une nouvelle branche
• git branch = lister les branches ; git branch -a = toutes (remote inclus)
• git merge feature/xx = fusionner la branche dans la branche courante
• Conflit de merge = deux branches ont modifié la même ligne → résolution manuelle
• Merge Request (GitLab) / Pull Request (GitHub) = demande de merge avec revue de code
• Bonne pratique : 1 branche par feature/bugfix, nommage feature/xx et bugfix/xx
• Objectif : main doit toujours être stable et déployable en production