Branches et fusion

Pourquoi travailler en branches

Modifier directement la branche principale (main) pour tester un changement risqué expose tout le monde à une version instable. Une branche permet de travailler sur un changement isolément, sans affecter le code principal, jusqu'à ce qu'il soit prêt.

git branch nouvelle-fonctionnalite       # créer une branche
git checkout nouvelle-fonctionnalite     # basculer dessus
git checkout -b nouvelle-fonctionnalite  # créer et basculer en une commande

Fusionner une branche

Une fois le travail terminé et validé sur la branche, il est fusionné (merge) dans main :

git checkout main
git merge nouvelle-fonctionnalite

flowchart LR
    A[main] --> B[Commit 1]
    B --> C[Commit 2]
    B --> D[branche: nouvelle-fonctionnalite]
    D --> E[Commit A]
    E --> F[Commit B]
    C --> G[main après merge]
    F --> G

Les conflits de fusion

Un conflit survient quand la même ligne d'un fichier a été modifiée différemment sur deux branches. Git ne peut pas décider automatiquement laquelle garder : il faut résoudre le conflit manuellement.

<<<<<<< HEAD
port: 8080
=======
port: 9090
>>>>>>> nouvelle-fonctionnalite

Il faut choisir la bonne valeur (ou les combiner), supprimer les marqueurs <<<<<<<, =======, >>>>>>>, puis committer la résolution.

Cas concret

Deux personnes modifient le même fichier de configuration sur des branches différentes : l'une change le port de 8080 à 9090, l'autre ajoute une ligne de commentaire juste au-dessus sans toucher au port. Au moment de la fusion, Git détecte que les deux changements touchent des zones proches et signale un conflit, même si sur le fond les deux modifications pourraient coexister : une intervention humaine tranche.

Erreurs fréquentes

• Paniquer face à un conflit de fusion et annuler toute la fusion : un conflit est normal et se résout ligne par ligne, ce n'est pas une erreur fatale.
• Résoudre un conflit sans comprendre les deux versions en jeu, gardant parfois la mauvaise valeur par précipitation.
• Oublier de supprimer les marqueurs de conflit (<<<<<<<, etc.) après résolution : le fichier reste syntaxiquement invalide, cassant potentiellement un script ou une configuration.

À retenir

• Une branche isole un travail en cours sans affecter la branche principale jusqu'à la fusion.
• Un conflit de fusion survient quand la même zone d'un fichier diverge entre deux branches, résolu manuellement.
• Toujours supprimer les marqueurs de conflit après résolution, avant de committer.

Mini-exercice

Après une fusion, un fichier de configuration contient encore les lignes <<<<<<< HEAD et =======. Le déploiement échoue avec une erreur de syntaxe. Quelle est la cause ?

Réponse : le conflit de fusion n'a pas été résolu correctement : les marqueurs de conflit Git n'ont pas été supprimés après le choix de la bonne valeur, laissant un fichier syntaxiquement invalide pour l'outil qui le lit ensuite.