Un parcours du tutoriel Résoudre les conflits de fusion : pourquoi la fusion du changement d'Alice entre en collision avec le vôtre, comment lire les marqueurs de conflit, et comment terminer la fusion.
Ce scénario vous place dans une situation très courante en équipe : un coéquipier et vous avez changé la même ligne, et Git a besoin de votre aide pour combiner les deux. Vous allez récupérer le travail de votre coéquipier, le fusionner dans votre branche, résoudre la collision à la main et terminer la fusion.
La situation
Vous êtes sur la branche feature/update-subtitle, où vous avez réécrit le sous-titre de la hero dans index.html. Pendant ce temps, votre coéquipière Alice a poussé sa propre modification de cette même ligne de sous-titre sur main.
Deux éditions différentes de la même ligne, sur deux branches. Git peut fast-forwarder ou auto-fusionner des changements qui touchent des endroits différents, mais quand les deux côtés modifient la même ligne, il ne peut pas deviner qui l'emporte. C'est un conflit de fusion, et vous seul pouvez décider du résultat.
Un conflit n'est pas une erreur de votre part. C'est Git qui fait une pause pour laisser un humain choisir, car les deux modifications sont chacune valides.
Y aller, étape par étape
Mettre main à jour
git checkout main
git pull
Basculer sur main et faire un pull récupère le changement de sous-titre d'Alice depuis le remote, et votre main local a maintenant son travail.
Fusionner main dans votre branche de feature
git checkout feature/update-subtitle
git merge main
Git tente de combiner la ligne de sous-titre d'Alice avec la vôtre, échoue sur cette ligne et signale un conflit dans index.html. La fusion s'arrête ici.
Ouvrir le fichier et lire les marqueurs
La région en conflit ressemble à ceci :
<<<<<<< HEAD
votre version du sous-titre
=======
la version d'Alice du sous-titre
>>>>>>> main
HEAD est votre branche ; la partie après ======= est le changement entrant depuis main.
Résoudre, puis terminer la fusion
git add index.html
git commit
Éditez index.html pour qu'il ne contienne que le seul sous-titre final que vous voulez, et supprimez les lignes <<<<<<<, ======= et >>>>>>>. Indexer le fichier indique à Git que le conflit est réglé, et le commit enregistre la fusion.
Lire les marqueurs de conflit
Les trois marqueurs apparaissent toujours dans le même ordre :
<<<<<<< HEAD à ======= : c'est votre côté.======= à >>>>>>> : c'est le côté entrant.- Résoudre signifie laisser le contenu voulu et retirer les trois lignes de marqueurs.
git status pendant un conflit liste les fichiers à résoudre sous « Unmerged paths ». Quand cette liste est vide, vous êtes prêt à commiter.
Ne laissez aucune ligne de marqueur dans le fichier. Un ======= oublié sera commité comme contenu réel et cassera la page. Cherchez les marqueurs dans le fichier avant de l'indexer.
Si vous voulez tout recommencer
Si une résolution part en vrille, vous pouvez abandonner toute la fusion et revenir à l'état d'avant :
git merge --abort
Les commandes de conflit de fusion que vous utiliserez vraiment
Au-delà de ce scénario, voici les commandes qui reviennent chaque fois que vous rencontrez un conflit :
- Voir quels fichiers sont en conflit —
git status, ou git diff --name-only --diff-filter=U pour juste la liste
- Ouvrir le conflit — éditez le fichier et retirez les marqueurs
<<<<<<<, =======, >>>>>>>, en gardant le contenu final
- Garder tout un côté d'un fichier d'un coup —
git checkout --ours <file> (votre branche) ou git checkout --theirs <file> (la branche entrante), puis git add <file>
- Terminer la fusion — indexez les fichiers résolus avec
git add, puis git commit (ou git merge --continue)
- Abandonner et revenir en arrière —
git merge --abort restaure l'état d'avant la fusion
Le moyen le plus rapide de se sentir à l'aise est de provoquer un conflit exprès dans le terminal ici et de le résoudre de plusieurs façons : à la main, avec --ours, et avec --theirs.