Comment résoudre les conflits de fusion Git sur la ligne de commande et dans un éditeur à trois voies

Pour résoudre les conflits de fusion dans Git, ouvrez chaque fichier que Git signale comme étant en conflit, décidez quel doit être le code entre les marqueurs <<<<<<<, ======= et >>>>>>>, supprimez les marqueurs, préparez le fichier avec git add et terminez avec git commit (ou git merge --continue). Pour revenir en arrière, exécutez git merge --abort. Ce guide parcourt cette boucle sur la ligne de commande, puis dans un éditeur visuel à trois voies, et se termine par les habitudes qui rendent les conflits plus rares et plus faciles à annuler. Pour mettre en pratique les choix qu'une fusion, un rebase ou un choix sélectionné en pause vous offre, suivez la leçon gratuite Continuer, ignorer ou abandonner une opération active.

Les exemples visuels utilisent GitTree, le client Git que nous créons pour macOS, Windows et Linux. Il exécute le Git installé sur votre ordinateur, donc cliquer et taper donne le même résultat ; la GitTree liste de fonctionnalités a une vue d'ensemble plus large.

Qu'est-ce qu'un conflit de fusion dans Git ?

Git fusionne ligne par ligne en utilisant trois versions de chaque fichier : la base (le dernier commit partagé par les deux branches), la nôtre (votre branche actuelle, HEAD) et la leur (la branche entrante, MERGE_HEAD). Si un seul côté a modifié une région, Git prend en compte ce changement. Si les deux côtés ont modifié les mêmes lignes différemment, Git s'arrête, écrit les deux versions dans le fichier et vous laisse la décision.

La même chose peut se produire dans git pull, git rebase, git cherry-pick, git revert et git stash pop. Le correctif est identique ; seule la commande finale diffère. git status étiquette chaque chemin en conflit :

• les deux modifiés : les deux branches ont modifié les mêmes lignes. C'est le cas courant.
• supprimé par nous / supprimé par eux : un côté a supprimé le fichier et l'autre l'a modifié, vous conservez donc le fichier modifié ou confirmez la suppression.
• tous deux ajoutés : chaque branche a créé un fichier différent au même chemin.

Comment résoudre les conflits de fusion sur la ligne de commande

1. Recherchez les fichiers en conflit

Git répertorie les conflits au moment où la fusion s'arrête et git status conserve la liste jusqu'à ce que vous ayez terminé. git diff --name-only --diff-filter=U imprime uniquement les chemins non fusionnés.

$ git merge feature/login
Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts
Automatic merge failed; fix conflicts and then commit the result.

$ git status
On branch main
You have unmerged paths.

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   src/auth.ts

2. Lisez les marqueurs de conflit

Tout ce qui se trouvait en dehors des marqueurs a fusionné proprement. Le bloc après <<<<<<< HEAD est votre branche actuelle, le bloc avant >>>>>>> feature/login est celui entrant et la ligne ======= les sépare.

export const retries = 3;
<<<<<<< HEAD
export const timeout = 45;
=======
export const timeout = 60;
>>>>>>> feature/login
export const debug = false;

Deux versions ne suffisent souvent pas pour trancher. Définissez le style de conflit zdiff3 de Git une fois, et chaque conflit affiche également la base, après une ligne ||||||| :

$ git config --global merge.conflictStyle zdiff3

<<<<<<< HEAD
export const timeout = 45;
||||||| 556e564
export const timeout = 30;
=======
export const timeout = 60;
>>>>>>> feature/login

Vous pouvez maintenant voir que main a augmenté le délai d'attente de 30 à 45 et la branche de fonctionnalités à 60 : décidez de la valeur dont le produit a besoin, et non de la branche qui gagne.

3. Modifiez le fichier et marquez-le comme résolu

Écrivez le code souhaité (un côté, l'autre, un mix ou quelque chose de nouveau) et supprimez chaque ligne de marqueur. Laissez Git vérifier les restes avant de procéder à la mise en scène, car un ======= parasite commis par accident est une construction classique cassée.

$ git diff --check          # lists any leftover conflict markers
$ git add src/auth.ts
$ git commit                # or: git merge --continue

Si la version d’une partie de l’ensemble du dossier est correcte, prenez-la directement. Pour que Git préfère un côté pour chaque élément en conflit pendant la fusion, démarrez la fusion avec git merge -X ours ou git merge -X theirs à la place ; les changements qui ne sont pas en conflit proviennent toujours des deux branches.

$ git checkout --ours -- src/auth.ts     # keep the current branch's version
$ git checkout --theirs -- src/auth.ts   # keep the incoming version
$ git add src/auth.ts

4. Terminez l'opération

Lorsque chaque fichier est transféré, continuez ce qui a été arrêté : git commit (ou git merge --continue), git rebase --continue, git cherry-pick --continue ou git revert --continue. Un rebase peut s'arrêter à nouveau lors d'une validation ultérieure ; répétez la boucle.

Résoudre les conflits de fusion dans une interface graphique : un résolveur de conflits Git à trois voies

Les marqueurs conviennent parfaitement pour un affrontement à deux lignes. Avec une douzaine de conflits dans un long fichier, un résolveur de conflits GUI est plus rapide et beaucoup plus difficile à se tromper. Un bon outil de fusion de conflits Git affiche les trois versions ensemble, vous permet de décider conflit par conflit et refuse de sauvegarder tant que les marqueurs restent.

Dans GitTree, une fusion qui s'arrête affiche une bannière avec le nombre de conflits et une liste des fichiers en conflit. Ouvrez-en une et l'éditeur prend toute la fenêtre : les branches actuelles et entrantes côte à côte en haut, chacune étiquetée avec son nom de branche, et la Sortie, le fichier tel qu'il sera enregistré, en dessous.

• Par conflit : prenez le camp actuel, le camp entrant, les deux ou aucun des deux, ou choisissez une seule ligne de chacun.
• Modifiez la sortie à la main pour tout ce que les boutons ne couvrent pas.
• Afficher la base pour voir l'ancêtre commun (Git l'écrit lorsque merge.conflictStyle vaut diff3 ou zdiff3).
• Annuler le choix pour revenir en arrière sur vos décisions.
• Fichiers supprimés : lorsqu'un côté a supprimé un fichier, l'autre l'a modifié, conservez le fichier de ce côté ou confirmez la suppression.

GitTree n'enregistrera pas un résultat contenant encore des lignes de marqueur. Il peut également ouvrir le fichier dans votre outil de fusion externe : VS Code, Cursor, JetBrains IDE, Beyond Compare, Meld, KDiff3, P4Merge, WinMerge, un programme personnalisé ou le propre merge.tool de Git. Si l'outil se ferme sans résoudre le fichier, le fichier reste en conflit.

Prédire les conflits de fusion avant de fusionner

Depuis Git 2.38, git merge-tree --write-tree effectue une fusion en mémoire sans lire ni écrire votre arbre ou index de travail, et sans effectuer de validation. Avec --name-only, il répertorie les fichiers qui seraient en conflit ; l'état de sortie est 1 en cas de conflits et 0 lorsque la fusion serait propre.

$ git fetch
$ git merge-tree --write-tree --name-only HEAD origin/main
0d708adc4a836d088802870278cb1f3daf06355f
src/auth.ts

Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts

GitTree exécute cet aperçu pour vous : la boîte de dialogue de fusion affiche le résultat prédit avant que vous confirmiez. Après chaque récupération, il vérifie également votre branche par rapport à sa branche amont et à la branche de base (principale ou maître sauf si vous en définissez une autre) et affiche un avertissement à côté du nom de la branche, tel que « Serait en conflit avec main dans 2 fichiers ». Un deuxième indice indique que les fichiers que vous modifiez sont également modifiés par d'autres branches récupérées et non fusionnées.

Les deux vérifications utilisent uniquement ce que vous avez déjà récupéré : rien n'est récupéré, fusionné ou modifié pour les calculer, et rien ne quitte votre ordinateur. L’un ou l’autre peut être désactivé dans les Préférences.

Réutiliser les résolutions de conflits avec git rerere

Rerere signifie « réutilisation de la résolution enregistrée ». Une fois activé, Git enregistre chaque conflit et la manière dont vous l'avez résolu. Lorsque le même conflit revient, par exemple lors d'un rebase répété d'une branche de longue durée ou d'une fusion que vous refaites, Git écrit votre résolution antérieure dans le fichier.

$ git config --global rerere.enabled true
$ git rerere forget src/auth.ts   # drop a recorded resolution that was wrong

Git laisse le résultat réutilisé sans préparation pour examen, sauf si rerere.autoUpdate est défini. Dans GitTree, les paramètres du référentiel ont des commutateurs Réutiliser les résolutions enregistrées (rerere) et Stage réutilisées pour ces options Git ; la vue des conflits étiquette une résolution réutilisée et Oublier la résolution en supprime une mauvaise.

Comment abandonner ou annuler une fusion dans Git

Pour annuler une fusion arrêtée en raison de conflits, exécutez git merge --abort. Un rebase, un Cherry-pick ou un Revert a son propre abandon :

$ git merge --abort
$ git rebase --abort
$ git cherry-pick --abort
$ git revert --abort

La propre documentation de Git avertit que git merge --abort ne peut pas toujours reconstruire les modifications non validées que vous aviez au démarrage de la fusion. Validez ou cachez avant de fusionner, et l'abandon n'a que du travail validé à restaurer.

Dans GitTree, Abort Merge (ou Abort Rebase, Cherry-Pick, Revert) explique d'abord que Git restaure la branche, l'index et la copie de travail d'avant l'opération et supprime les résolutions effectuées jusqu'à présent. GitTree enregistre tout ce que l'abandon supprime, planifié ou non, dans des instantanés de récupération, afin que l'annulation puisse le restaurer.

Comment annuler une fusion après l'avoir validée

La marche à suivre dépend si vous avez poussé ou non la fusion :

# Not pushed yet, right after the merge:
$ git reset --hard ORIG_HEAD     # also discards uncommitted changes
$ git reset --merge ORIG_HEAD    # keeps uncommitted changes

# Already pushed:
$ git revert -m 1 <merge-commit> # a new commit that reverses it

Une fusion enregistre le conseil précédent de votre branche dans ORIG_HEAD, donc la réinitialisation supprime la fusion, à moins qu'une réinitialisation ou un rebase ultérieur n'ait déplacé ORIG_HEAD. Une fois que d’autres ont fusionné, revenez à la place. L'annulation d'une fusion indique à Git que vous ne voulez jamais ces modifications : fusionner à nouveau cette branche ne les ramènera pas à moins que vous n'annuliez l'annulation.

Dans GitTree, sélectionnez le premier parent de la fusion (le commit sur lequel se trouvait votre branche auparavant) dans le graphique et choisissez une réinitialisation logicielle, mixte ou matérielle dans le menu de validation, chacune étant étiquetée avec ce qu'elle conserve. GitTree capture 19 types d'opérations avant leur exécution, réinitialisations incluses, afin que l'annulation puisse inverser la réinitialisation et que la vue reflog récupère les états plus anciens. Le guide pour annuler une réinitialisation, un rebase ou un commit couvre la récupération en profondeur.

Comment éviter la plupart des conflits de fusion

• Gardez les branches petites et de courte durée. Plus les deux branches divergent longtemps, plus elles se touchent toutes les deux.
• Apportez souvent la branche de base, pas une seule fois à la fin.
• Séparez le formatage de la logique. Convenez d'un seul formateur et effectuez seul le reformatage du fichier entier.
• Régénérez les fichiers de verrouillage au lieu de les fusionner manuellement. Prenez l'un ou l'autre côté, puis exécutez à nouveau votre gestionnaire de packages.
• Activez zdiff3 et relancez-le une fois. Deux commandes, un avantage durable.
• Commitez ou cachez avant l'intégration, afin que chaque abandon et annulation soit exact.

Vous voulez d’abord vous entraîner sur un référentiel sécurisé ? La leçon gratuite Fusionner les branches divergentes et vérifier les deux parents dans les Tutoriels Git présente une véritable fusion. Vous évaluez toujours le terminal par rapport à une interface graphique ? Git GUI vs command line compare les deux honnêtement.

GitTree propose un forfait gratuit qui couvre toutes les fonctionnalités de Git, dépôts privés inclus, et Nour, l'assistant IA, est livré avec GitTree Pro (voir tarifications) ; il a besoin de Git 2.39 ou plus récent et d'un compte GitTree pour se connecter. Obtenez-le pour macOS, Windows ou Linux, ou consultez tous les installateurs sur la GitTree page de téléchargement. Le Ubuntu 22.04, mettez d'abord à niveau Git. Coincé dans un conflit tenace ? Demandez à l'assistance GitTree.