Résoudre les conflits de merge Git visuellement — guide pas à pas

Pourquoi les conflits de merge font peur aux développeurs (et pourquoi ils ne devraient pas)

Si vous avez utilisé Git pendant un certain temps, vous avez presque certainement rencontré le redouté conflit de merge. Ce moment où Git vous annonce qu'il ne peut pas fusionner automatiquement vos modifications peut donner l'impression de se heurter à un mur. Beaucoup de développeurs, surtout en début de carrière, considèrent les conflits de merge comme quelque chose qui a mal tourné. Mais la réalité est plus simple : les conflits de merge font partie intégrante du développement collaboratif. Il suffit d'adopter la bonne approche pour les résoudre efficacement.

Qu'est-ce qu'un conflit de merge ?

Un conflit de merge survient quand Git ne peut pas combiner automatiquement les modifications provenant de deux branches différentes. Cela se produit généralement quand deux personnes (ou même une seule personne sur des branches différentes) modifient les mêmes lignes dans le même fichier.

Quand Git détecte un conflit, il insère des marqueurs de conflit directement dans les fichiers concernés :

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/update-timeout

Tout ce qui se trouve entre <<<<<<< HEAD et ======= correspond à votre version (souvent appelée "ours"). Tout ce qui se trouve entre ======= et >>>>>>> correspond à la version entrante ("theirs"). Votre rôle est de décider quel doit être le résultat final, de supprimer les marqueurs et d'indiquer à Git que le conflit est résolu.

La méthode traditionnelle : modifier les marqueurs de conflit à la main

L'approche la plus basique consiste à ouvrir le fichier en conflit dans un éditeur de texte, à rechercher chaque groupe de marqueurs de conflit et à modifier le code manuellement. Pour un seul conflit dans un petit fichier, cela fonctionne très bien. Mais la tâche devient vite pénible quand vous devez gérer :

• Plusieurs conflits dispersés dans un même fichier
• Plusieurs fichiers en conflit dans le même merge
• Des modifications complexes où il faut combiner des parties des deux versions
• Des conflits imbriqués ou adjacents où les marqueurs sont difficiles à lire

Modifier les marqueurs manuellement est source d'erreurs. Il est facile d'oublier un marqueur, de supprimer le mauvais bloc ou d'introduire un bug subtil parce que vous avez perdu le fil de ce que chaque version essayait de faire. Il doit y avoir une meilleure façon de procéder.

La méthode visuelle : utiliser un éditeur de merge à 3 voies

Qu'est-ce que le merge à 3 voies ?

Un merge à 3 voies vous montre trois versions du fichier en même temps :

• Base -- l'ancêtre commun, c'est-à-dire la version du fichier avant que l'une ou l'autre branche n'ait apporté de modifications
• Ours -- la version du fichier dans votre branche
• Theirs -- la version du fichier dans la branche entrante

Avoir les trois versions visibles en même temps change tout. Au lieu de fixer des marqueurs de conflit en essayant de reconstituer ce qui s'est passé, vous pouvez voir exactement ce que chaque côté a modifié par rapport à l'original. Ce contexte rend la résolution de chaque conflit beaucoup plus facile.

Comment ça fonctionne dans GitSquid

GitSquid intègre un éditeur de merge à 3 voies conçu pour rendre la résolution de conflits simple, même si vous n'avez jamais résolu de conflit auparavant. Voici à quoi ressemble le processus :

1. Voir tous les fichiers en conflit d'un coup d'œil. Quand un merge produit des conflits, le panneau de conflits liste tous les fichiers concernés. Vous savez immédiatement l'étendue de ce qui doit être résolu.

2. Ouvrir l'éditeur à 3 voies. Cliquez sur n'importe quel fichier en conflit pour l'ouvrir dans l'éditeur de merge. Vous verrez trois colonnes côte à côte : Base à gauche, Ours au centre et Theirs à droite. Chaque colonne affiche le contenu complet du fichier avec la coloration syntaxique, pour que vous puissiez lire le code en contexte.

3. Résoudre les conflits bloc par bloc. Chaque conflit est mis en évidence et présenté comme un bloc distinct. Pour chaque conflit, vous disposez de boutons d'action clairs :

• Use Ours -- conserver votre version du code en conflit
• Use Theirs -- accepter la version entrante à la place
• Use Both -- inclure les deux modifications, l'une après l'autre

Un clic et le conflit est résolu. Plus besoin de chercher des marqueurs, plus de risque de supprimer les mauvaises lignes par accident.

4. Affiner le résultat. Sous les trois colonnes, un panneau de résultat affiche le fichier fusionné dans un éditeur de code complet propulsé par CodeMirror 6 avec coloration syntaxique. Si aucune des options en un clic ne produit exactement ce dont vous avez besoin, vous pouvez modifier le résultat directement. C'est utile quand vous devez combiner des parties des deux versions de manière personnalisée, par exemple en conservant la signature d'une fonction d'une branche mais l'implémentation d'une autre.

5. Marquer comme résolu. Une fois satisfait du résultat, marquez le fichier comme résolu et passez au fichier en conflit suivant. Quand tous les fichiers sont résolus, vous pouvez finaliser le merge.

L'avantage principal est que vous ne perdez jamais le contexte. Vous pouvez toujours voir à quoi ressemblait le code avant que l'une ou l'autre branche ne le modifie, ce que chaque branche a changé, et quel sera le résultat final. Cette clarté élimine la majeure partie de l'anxiété liée aux conflits de merge.

Conseils pour éviter les conflits de merge

Même avec de bons outils, prévenir les conflits reste toujours préférable à les résoudre. Voici quelques bonnes habitudes qui font la différence :

• Faites des pull régulièrement. Plus vous attendez avant d'intégrer les modifications de la branche principale, plus votre code diverge du travail de vos coéquipiers. Faire des pull régulièrement réduit l'écart et diminue les risques de modifications qui se chevauchent.
• Gardez des branches à courte durée de vie. Une branche de fonctionnalité qui vit pendant deux semaines accumule bien plus de conflits potentiels qu'une branche qui vit deux jours. Découpez les grandes fonctionnalités en incréments plus petits et fusionnables.
• Communiquez avec votre équipe. Si deux personnes doivent travailler sur le même fichier ou module, un petit avertissement peut faire gagner du temps par la suite. La coordination n'a pas besoin d'être formelle ; un message rapide suffit souvent.
• Utilisez des feature flags. Au lieu de maintenir une branche de longue durée pour une fonctionnalité qui n'est pas prête à être livrée, fusionnez-la derrière un feature flag. Le code est intégré en continu, mais la fonctionnalité reste masquée jusqu'à ce qu'elle soit terminée.

Les conflits de merge sont normaux

Les conflits de merge ne sont pas le signe que quelque chose a mal tourné. Ils sont une conséquence naturelle du fait que plusieurs personnes travaillent sur le même code, ce qui est précisément ce que le contrôle de version est conçu pour gérer. La différence entre une expérience frustrante et une expérience fluide dépend généralement des outils que vous utilisez.

Un éditeur de merge visuel à 3 voies élimine les approximations. Au lieu de déchiffrer des marqueurs de conflit dans un éditeur de texte, vous voyez chaque version du code, vous choisissez la résolution qui a du sens et vous passez à la suite. Avec l'éditeur de merge intégré de GitSquid, résoudre des conflits devient simplement une étape du workflow plutôt qu'une source d'appréhension.