Résoudre les conflits de merge Git

Git affiche CONFLICT et vous ne savez pas quoi faire ? Ce guide vous accompagne pas à pas : lire les marqueurs, choisir la bonne version, résoudre proprement et éviter les pièges classiques. Vous apprendrez aussi à utiliser rerere pour ne plus résoudre deux fois le même conflit, et à annuler un merge mal parti.

Prérequis : Merge et conflits et Rebase fondamental.

Piège classique : --ours et --theirs sont inversés pendant un rebase

Si vous résolvez des conflits pendant un rebase (pas un merge), les sens de --ours et --theirs sont inversés par rapport à ce que vous attendez :

Contexte	--ours	--theirs
Merge	Branche courante (la vôtre)	Branche mergée (l’autre)
Rebase	Branche cible (souvent main)	Vos commits rejoués

Glissez pour voir

Pendant un rebase, --ours désigne la branche sur laquelle vous rebasez, et --theirs désigne vos propres commits. C’est l’inverse du merge. Voir la section « Utiliser —ours et —theirs » plus bas.

Ce que vous allez apprendre

• Lire les marqueurs de conflit <<<<<<<, =======, >>>>>>> sans panique
• Résoudre un conflit manuellement étape par étape
• Utiliser --ours et --theirs pendant un rebase pour résoudre vite
• Annuler proprement un merge ou rebase conflictuel avec --abort
• Configurer rerere pour mémoriser vos résolutions récurrentes

Pourquoi Git ne résout-il pas tout seul ?

Git fusionne automatiquement les modifications quand elles touchent des fichiers ou zones différentes. Un conflit apparaît quand deux branches modifient la même zone du même fichier — Git ne peut pas deviner quelle version garder.

Situations typiques qui créent des conflits :

• Deux développeurs modifient la même fonction
• Une branche renomme un fichier, l’autre le modifie
• Deux branches ajoutent du code au même endroit

Lire les marqueurs de conflit

Quand un conflit survient, Git insère des marqueurs dans le fichier :

<<<<<<< HEAD
function calculerTVA(prix) {
  return prix * 0.20;
}
=======
function calculerTVA(prix, taux = 0.20) {
  return prix * taux;
}
>>>>>>> feature/tva-configurable

Marqueur	Signification
<<<<<<< HEAD	Début de votre version (branche courante)
=======	Séparation entre les deux versions
>>>>>>> feature/...	Fin de la version de l’autre branche

Glissez pour voir

Votre travail : choisir quelle version garder (ou combiner les deux), puis supprimer les marqueurs.

Résoudre un conflit manuellement

1. Identifiez les fichiers en conflit

   git status

   Les fichiers en conflit apparaissent sous “Unmerged paths” avec le statut both modified.

2. Ouvrez le fichier et éditez

   Supprimez les marqueurs et gardez le code correct. Par exemple, si vous voulez combiner les deux approches :

   function calculerTVA(prix, taux = 0.20) {
     return prix * taux;
   }

3. Marquez le conflit comme résolu

   git add src/utils/tva.js

4. Terminez le merge

   git commit

   Git préremplira le message avec Merge branch 'feature/...'.

Pour voir la liste complète des conflits restants :

git diff --name-only --diff-filter=U

Utiliser —ours et —theirs

Quand vous savez d’avance quelle version garder, vous pouvez résoudre le conflit en une commande :

# Garder VOTRE version (branche courante)
git checkout --ours src/utils/tva.js
git add src/utils/tva.js

# Garder la version de L'AUTRE branche
git checkout --theirs src/utils/tva.js
git add src/utils/tva.js

Pour appliquer la même stratégie à tous les fichiers en conflit :

# Garder tous les fichiers de la branche courante
git checkout --ours .
git add .

# Garder tous les fichiers de l'autre branche
git checkout --theirs .
git add .

⚠️ --ours et --theirs sont INVERSÉS pendant un rebase

C’est le piège classique. Pendant un rebase, Git rejoue vos commits sur l’autre branche. Du point de vue de Git :

Contexte	--ours	--theirs
Merge	Branche courante (la vôtre)	Branche mergée (l’autre)
Rebase	Branche cible (l’autre !)	Vos commits rejoués

Glissez pour voir

Pendant un rebase, --ours est la branche sur laquelle vous rebasez (souvent main) et --theirs est votre travail. C’est l’inverse du merge.

Annuler un merge raté

Si le merge est trop complexe ou si vous avez fait une erreur, vous pouvez tout annuler et revenir à l’état d’avant :

Pendant le merge (conflits non résolus)

git merge --abort

Le working directory revient exactement à l’état d’avant git merge.

Après le commit de merge

Si vous avez déjà commité le merge mais regrettez :

git reset --hard HEAD~1

Ou si le merge est déjà poussé :

git revert -m 1 HEAD

Pendant un rebase

git rebase --abort

Revient à l’état d’avant le rebase — aucune modification perdue.

Activer rerere : ne résoudre qu’une fois

rerere (reuse recorded resolution) mémorise comment vous résolvez un conflit et réapplique automatiquement la même résolution si le conflit réapparaît :

git config --global rerere.enabled true

Comment ça fonctionne :

1. Vous résolvez un conflit manuellement
2. Git enregistre la résolution dans .git/rr-cache/
3. La prochaine fois que le même conflit survient (ex : rebase répété), Git le résout automatiquement

Vérification — après avoir activé rerere et résolu un conflit :

git rerere status

Idéal pour les rebases répétés

Si vous rebasez régulièrement votre branche feature sur main, vous rencontrerez souvent les mêmes conflits. Avec rerere, vous ne les résolvez qu’une seule fois.

Conflits sur les fichiers binaires

Les fichiers binaires (images, PDF, archives) ne peuvent pas être fusionnés ligne par ligne. Git ne peut que garder l’une ou l’autre version :

# Garder votre version de l'image
git checkout --ours logo.png
git add logo.png

# Garder la version de l'autre branche
git checkout --theirs logo.png
git add logo.png

Il n’y a pas de « combinaison » possible pour un fichier binaire.

Merge —squash comme alternative

Si vous anticipez beaucoup de conflits, merge --squash peut simplifier la situation en combinant tous les commits de la feature en un seul changement :

git merge --squash feature/dashboard

Cela applique toutes les modifications de feature/dashboard dans votre working directory sans créer de commit de merge. Résolvez les éventuels conflits, puis commitez :

git commit -m "feat: intégrer le dashboard"

L’avantage : un seul commit propre, pas d’historique de merge complexe. L’inconvénient : l’historique détaillé de la branche feature est perdu dans le merge.

Diagnostic : visualiser les conflits

Avant de résoudre, comprenez l’étendue des modifications :

# Voir ce que la branche feature a modifié
git diff main...feature/dashboard --stat

# Voir les modifications en conflit en détail
git diff

Pour un diff à 3 voies (base commune + les 2 branches) :

git config --global merge.conflictstyle diff3

Le format diff3 ajoute une section ||||||| montrant la version d’origine (avant les modifications des deux côtés) :

<<<<<<< HEAD
return prix * 0.20;
||||||| merged common ancestors
return prix * 0.196;
=======
return prix * taux;
>>>>>>> feature/tva-configurable

Cela aide à comprendre ce que chacun a voulu changer par rapport à l’original.

Dépannage : problèmes courants

Symptôme	Cause probable	Solution
Conflits sur des fichiers que vous n’avez pas touchés	Reformatage, fin de ligne, espaces	Vérifiez .gitattributes et core.autocrlf
merge --abort échoue	Modifications non commitées avant le merge	git stash puis git merge --abort
Le même conflit revient à chaque rebase	Résolution non mémorisée	Activez rerere : git config --global rerere.enabled true
--ours garde la mauvaise version pendant un rebase	Les sens sont inversés en rebase	Pendant un rebase, --ours = branche cible, --theirs = vos commits
Conflit « both deleted »	Les deux branches ont supprimé le fichier	git rm fichier pour confirmer la suppression
Conflit « both added »	Les deux branches ont créé le même fichier	Éditez le fichier pour garder le bon contenu, puis git add

Glissez pour voir

À retenir

• Marqueurs : <<<<<<< = votre version, ======= = séparation, >>>>>>> = l’autre version
• Résolution : éditez le fichier, supprimez les marqueurs, git add, git commit
• --ours/--theirs : attention, les sens sont inversés pendant un rebase
• git merge --abort : annulez tout et revenez à l’état d’avant
• rerere : activez-le (git config --global rerere.enabled true) pour ne plus résoudre deux fois le même conflit
• diff3 : activez le format 3 voies pour mieux comprendre l’origine du conflit
• Fichiers binaires : seul --ours ou --theirs, pas de fusion possible

Prochaines étapes

Débloquer un push rejeté Votre push est rejeté ? pull --rebase, force-with-lease et divergence.

Merge avancé Stratégies de merge, -Xours/-Xtheirs et merge --squash.

Annuler et corriger des commits Amend, revert, reset : toutes les techniques d'annulation.

×

📖 Voir la documentation →