Résoudre un conflit de fusion Git : guide pas à pas

Quand un git merge conflict apparaît à l'écran, le premier réflexe de la plupart des développeurs est de paniquer — alors qu'un conflit est en réalité la façon dont Git vous aide. Git constate que les mêmes lignes ont été modifiées différemment sur deux branches et ne peut pas décider quelle version est correcte : il s'arrête donc et vous rend la décision. Ce guide explique pas à pas pourquoi les conflits surviennent, comment lire les marqueurs dans le terminal et comment nettoyer le fichier en toute sécurité.

Qu'est-ce qu'un conflit de fusion, exactement ?

Git fusionne les modifications ligne par ligne. Lorsque deux branches touchent des zones différentes du même fichier, Git les combine sans problème. Un conflit n'apparaît que lorsque les mêmes lignes (ou des lignes très proches) ont été modifiées différemment sur les deux branches, ou qu'un côté a supprimé ce que l'autre a modifié. Dans ce cas, Git demande : « il y a deux vérités possibles ici, laquelle voulez-vous ? »

Les conflits peuvent surgir avec presque toutes ces commandes : git merge, git rebase, git pull (qui exécute une fusion ou un rebase en interne), git cherry-pick et git stash pop. Le mécanisme est identique partout : une fois que vous savez en résoudre un, vous savez les résoudre tous.

Lire le conflit : ce que signifient les marqueurs

En ouvrant un fichier en conflit, vous verrez trois marqueurs insérés par Git :

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/login

Entre <<<<<<< HEAD et ======= : votre côté (la branche sur laquelle vous êtes, « ours »).
Entre ======= et >>>>>>> : le côté entrant, la branche que vous fusionnez (« theirs »).
L'étiquette finale (feature/login) indique d'où vient la modification en conflit.

Un détail important : pendant un rebase, le sens de « ours » et « theirs » est inversé, car le rebase rejoue vos commits par-dessus la branche cible. Ainsi HEAD représente la branche cible et le bloc du bas contient votre modification. Gardez-le à l'esprit si vous résolvez en ligne de commande.

Résolution pas à pas

Voici un flux sûr et reproductible :

Observez l'état. Lancez git status ; il liste les fichiers en conflit sous la rubrique « Unmerged paths ».
Ouvrez chaque fichier en conflit. Repérez chaque bloc de marqueurs. Vous avez trois options : garder votre côté, garder le côté entrant, ou fusionner les deux à la main.
Écrivez le bon résultat. Vous devez supprimer les trois lignes de marqueurs (<<<<<<<, =======, >>>>>>>) pour ne laisser que le code final souhaité.
Marquez-le comme résolu. Indexez le fichier avec git add <fichier>.
Terminez l'opération. Continuez avec git commit pour une fusion, git rebase --continue pour un rebase, ou git cherry-pick --continue pour un cherry-pick.

Le support de l'éditeur facilite grandement les choses. VS Code surligne les blocs en conflit et affiche les boutons « Accept Current Change / Accept Incoming Change / Accept Both Changes ». Néanmoins, avant de cliquer, vérifiez que le résultat a vraiment du sens : l'acceptation automatique ne produit pas toujours le bon code.

Décisions rapides en ligne de commande

Parfois, vous savez que vous voulez un côté entier d'un fichier, du début à la fin. Plutôt que d'éditer à la main :

# garder entièrement la version de ma branche pour ce fichier
git checkout --ours config/app.php
# garder entièrement la version de la branche entrante
git checkout --theirs config/app.php
# puis l'indexer
git add config/app.php

Si vous voulez revenir complètement au point précédant le conflit, git merge --abort (ou git rebase --abort pour un rebase) vous ramène à l'état de départ. C'est la manière la plus propre de recommencer sans rien casser.

Réduire les conflits en amont

Le meilleur conflit est celui qui n'arrive jamais. Quelques habitudes réduisent nettement le risque :

Commitez petit et souvent, intégrez fréquemment. Garder une branche éloignée de main pendant des semaines invite les conflits à s'accumuler. Restez à jour avec git pull --rebase.
Gardez des fichiers petits et ciblés. Une structure modulaire, plutôt que d'énormes fichiers uniques, réduit les chances que deux personnes touchent la même ligne.
Méfiez-vous des fichiers générés. Les fichiers de verrouillage comme composer.lock et package-lock.json entrent souvent en conflit ; les régénérer (par ex. composer install) est plus sûr que de les éditer à la main.
Standardisez le formatage. Un formateur partagé dans l'équipe (Prettier, PHP-CS-Fixer) élimine les faux conflits dus uniquement à l'indentation ou aux espaces.

Vérifier votre résolution

Après avoir fermé un conflit, vérifier « est-ce que ça compile » ne suffit pas. Assurez-vous que les deux côtés de la modification fusionnée ont gardé leur intention : lancez les tests, ouvrez l'application et exercez manuellement le comportement lié à la zone en conflit. Revoir l'état final avec git diff avant de committer est un moyen rapide de repérer une ligne >>>>>>> oubliée ou du vieux code qui aurait dû être supprimé.

Questions fréquentes

J'ai gardé le mauvais côté pendant la résolution — puis-je annuler ?

Si vous n'avez pas encore committé, git merge --abort annule toute la fusion pour recommencer. Si vous avez déjà committé, utilisez git reflog pour trouver le HEAD précédent et git reset --hard <hash> pour y revenir. C'est précisément pourquoi il ne faut pas pousser avant d'avoir vérifié sa résolution.

Je résous sans cesse les mêmes conflits — y a-t-il une solution ?

Oui. Activez rerere (reuse recorded resolution) avec git config --global rerere.enabled true. Git mémorise comment vous avez résolu un conflit et le réapplique automatiquement s'il réapparaît — très utile lors de longs rebases.

Pourquoi « ours » et « theirs » diffèrent-ils entre merge et rebase ?

Dans une fusion, la branche sur laquelle vous êtes est « ours ». Dans un rebase, Git prend d'abord la branche cible comme base et rejoue vos commits par-dessus : les rôles s'inversent. HEAD représente la branche cible et « theirs » est votre modification rejouée. Vérifiez dans quelle commande vous êtes avant de décider.

Les conflits ralentissent votre projet ? Nous pouvons rationaliser ensemble votre flux Git, votre stratégie de branches et votre processus de déploiement. Si vous voulez de l'aide sur votre projet, contactez-moi.