Résoudre un conflit de fusion, sans paniquer
Résumé : le merge conflict est le grand cauchemar des débutants Git. C'est pourtant un mécanisme volontaire et bienveillant : Git détecte qu'il ne peut pas décider tout seul, et demande à un humain de trancher. Cette leçon explique pourquoi les conflits apparaissent, comment les lire, et donne les 5 étapes pour les résoudre proprement.
1. Pourquoi un conflit apparaît
Git fusionne automatiquement 95 % des changements, tant que les modifications portent sur des zones différentes du code. Un conflit apparaît uniquement dans un cas précis : quand deux personnes ont modifié la même ligne du même fichier.
Point crucial : ce n'est pas un bug, c'est une sécurité. Sans Git, la modification d'Alice écraserait silencieusement celle de Bob (ou vice-versa). Un conflit signalé, c'est un désastre évité.
2. À quoi ressemble un conflit dans un fichier
Quand Git détecte un conflit, il modifie le fichier en insérant des marqueurs de conflit qui délimitent les zones à arbitrer.
Voici à quoi ressemble un fichier en conflit :
server:
host: 0.0.0.0
port: 8080
<<<<<<< HEAD
timeout: 60
=======
timeout: 120
>>>>>>> feature/paiement
database:
url: postgres://localhost/app
Décodage :
| Marqueur | Signification |
|---|---|
<<<<<<< HEAD | Début de la version actuelle (votre branche cible, souvent main) |
======= | Séparateur entre les deux versions |
>>>>>>> feature/paiement | Fin de la version entrante (la branche que vous êtes en train de fusionner) |
Entre <<<<<<< HEAD et ======= : ce que dit votre branche actuelle.
Entre ======= et >>>>>>> : ce que dit la branche entrante.
Votre travail : décider quelle version garder, ou fusionner les deux à la main, puis supprimer tous les marqueurs.
3. Les 5 étapes pour résoudre un conflit proprement
Ne paniquez pas. Toujours suivre la même séquence.
Étape 1 · Lire — identifier les zones
git status (ou l'onglet Git de votre éditeur) affiche la liste des fichiers en conflit. Ouvrez-les un par un.
Un fichier peut contenir plusieurs zones de conflit — chacune est délimitée par son propre triplet <<<<<<< / ======= / >>>>>>>.
Étape 2 · Comprendre — le pourquoi de chaque version
Avant de choisir, prenez 30 secondes pour comprendre pourquoi les deux versions existent.
- Regardez le nom de la branche entrante (
feature/paiement,hotfix/security) — le contexte donne un indice. - Regardez qui a fait le commit d'origine (
git blame, ou l'auteur affiché dans l'éditeur). - Si le doute persiste, allez voir la personne concernée ou demandez sur le canal Slack de l'équipe. Aucun conflit ne mérite d'être résolu en aveugle.
Étape 3 · Arbitrer — quatre issues possibles
Pour chaque zone de conflit, quatre issues sont possibles :
| Issue | Quand la choisir |
|---|---|
| Garder la version actuelle (HEAD) | La modification de l'autre branche est obsolète ou fausse |
| Garder la version entrante | Votre version est obsolète ou fausse |
| Combiner les deux à la main | Les deux modifications sont légitimes et se complètent |
| Écrire une troisième version | Aucune des deux n'est bonne, il faut synthétiser |
Cas le plus fréquent : combiner les deux. Par exemple si Alice met timeout: 60 et Bob met timeout: 120, la vraie question à poser à l'équipe est « pourquoi ce timeout doit changer ? » — la réponse dicte la bonne valeur, qui n'est peut-être ni 60 ni 120.
Étape 4 · Nettoyer — supprimer les marqueurs
Aucun marqueur ne doit rester dans le fichier final. Une recherche <<<<<<< dans votre projet doit renvoyer zéro résultat.
Astuce : la plupart des éditeurs modernes (VS Code, JetBrains, Sublime) affichent les conflits avec des boutons cliquables :
- « Accept Current Change » (garder HEAD)
- « Accept Incoming Change » (garder l'entrante)
- « Accept Both Changes » (combiner)
- « Compare Changes » (diff visuel)
Ces boutons suppriment les marqueurs automatiquement après le choix.
Étape 5 · Valider — tester avant de commit
Avant de créer le commit de fusion, lancez toujours les tests. Un conflit mal résolu peut compiler mais casser en production.
Une fois les tests verts, indexez tous les fichiers résolus et créez le commit. Git génère alors un commit de fusion avec un message par défaut du type Merge branch 'feature/paiement' into main.
4. Les trois erreurs classiques à éviter
Chacune de ces trois erreurs peut être détectée automatiquement :
- Erreur 1 : imposer une revue de code sur chaque fusion — un collègue relira et repérera.
- Erreur 2 : configurer votre CI/CD pour échouer dès qu'il détecte
<<<<<<<dans un fichier. - Erreur 3 : rendre les tests obligatoires dans les branch protection rules de GitHub/GitLab.
5. Comment éviter les conflits, en amont
Un conflit est toujours résolvable, mais le meilleur conflit est celui qui n'a pas lieu. Quatre habitudes simples divisent leur fréquence par 10.
Ces habitudes sont la vraie compétence Git — pas la maîtrise des commandes, mais la discipline d'équipe qui empêche les conflits d'apparaître en premier lieu.
6. Le cas particulier du rebase
Il existe une deuxième situation où on rencontre des conflits : lors d'un rebase. Le rebase « rejoue » vos commits par-dessus une autre base — utile pour garder un historique linéaire, mais chaque commit rejoué peut créer un conflit individuel.
Différence importante :
- Un conflit de merge : un seul conflit à résoudre, une fois pour toute la fusion.
- Un conflit de rebase : potentiellement un conflit par commit rejoué. Peut vite devenir douloureux.
Recommandation pour un débutant : privilégiez merge à rebase tant que vous n'êtes pas à l'aise. Le rebase est un outil puissant, mais qui se maîtrise sur plusieurs mois de pratique. C'est traité en profondeur dans le Cours Premium Git.
7. En cas de doute absolu — la commande de sortie de secours
Si vous êtes complètement perdu·e au milieu d'un conflit, il y a toujours un bouton d'arrêt d'urgence : annuler la fusion en cours et revenir à l'état précédent.
Concrètement, la commande est git merge --abort (ou git rebase --abort en cas de rebase). Elle est totalement sûre : elle ne détruit aucun commit, elle annule uniquement l'opération en cours.
À retenir : dans Git, presque tout est réversible. Un conflit mal négocié ne va jamais casser votre journée si vous connaissez cette commande.
Retenir en 30 secondes
- Un conflit apparaît uniquement quand deux personnes modifient la même ligne du même fichier.
- Ce n'est pas un bug, c'est une sécurité — sans Git, la modification aurait été écrasée en silence.
- La résolution suit 5 étapes : lire, comprendre, arbitrer, nettoyer, valider.
- Ne laissez jamais un marqueur
<<<<<<<dans un fichier commit. - Toujours relancer les tests après avoir résolu un conflit.
- En cas de panique, la commande d'annulation ramène tout à l'état d'avant.
Suivant : Git dans CI/CD et l'open source →