Résoudre un conflit en préservant l’intention

Deux personnes modifient parfois la même zone de index.html : l’une actualise le texte d’introduction, l’autre ajoute la section « Nouveaux guides ». Git peut alors interrompre un rebase ou une fusion, car il ne peut pas déduire seul le résultat voulu. Votre travail consiste à comprendre les deux intentions, puis à décider du contenu qui doit rester.

Dans la leçon précédente, vous avez appris à repérer l’opération interrompue et les fichiers concernés. Ici, vous vous concentrez sur la comparaison et la décision éditoriale : un conflit ne se résout pas en choisissant systématiquement « votre version » ou « l’autre version ». Il faut préserver le sens fonctionnel de chaque changement compatible.

Identifier les versions à comparer

Pendant un conflit, Git conserve les contenus des deux côtés dans l’index. Le stage 2 correspond à la version de la branche sur laquelle l’opération est en cours ; le stage 3 correspond au changement que Git essaie d’y appliquer. Lors d’un rebase, cette lecture peut surprendre : la branche de travail est rejouée sur la branche de destination, donc « ours » et « theirs » ne correspondent pas toujours à l’idée intuitive de « ma branche » et « la branche des autres ».

git show :1:index.html
git show :2:index.html
git show :3:index.html

Chaque commande affiche une version de index.html dans l’index de conflit : :1 est la base commune, :2 le côté sur lequel Git opère, :3 le changement appliqué. Ces versions sont disponibles pour le fichier non fusionné ; leur présence dépend du conflit rencontré.

La base commune, au stage 1, aide à repérer ce qui existait avant les modifications concurrentes. Comparez ensuite les stages 2 et 3 en vous demandant ce que chacun cherchait à accomplir, et pas seulement quelles lignes diffèrent. Par exemple, l’un peut améliorer le texte de présentation tandis que l’autre ajoute les cartes de guides : si ces intentions ne s’excluent pas, la version finale doit réunir les deux résultats.

Construire une résolution cohérente

Ouvrez le fichier concerné dans votre éditeur et examinez le bloc signalé par Git. Les marqueurs <<<<<<<, ======= et >>>>>>> encadrent les versions en conflit ; ils servent de repères, pas de contenu à conserver dans la page. Déterminez quelles lignes répondent encore au besoin, puis éditez le fichier pour écrire une version finale lisible, sans marqueur.

Dans le projet Sentiers, imaginez que le texte de l’introduction a été rendu plus précis sur une branche, tandis que l’autre a ajouté « Nouveaux guides » dans le contenu principal. Si les deux changements sont toujours souhaités, gardez l’introduction révisée et les cartes ajoutées, en respectant l’ordre et la structure du squelette fourni. Si les deux côtés ont modifié le même titre ou le même lien, choisissez une formulation et une destination cohérentes avec la fonctionnalité ; ne recopiez pas mécaniquement les deux variantes.

La résolution est sémantique : vous choisissez le résultat en fonction du comportement et du contenu attendus, pas selon le nombre de lignes conservées. Relisez les éléments voisins pour vérifier que le texte final s’intègre à la page et que les éléments de navigation et les sections gardent leur cohérence. Ne modifiez que les fichiers concernés par le conflit et n’ajoutez pas de changement sans rapport.

Préparer la suite sans précipiter l’opération

Une fois votre choix éditorial établi, enregistrez le fichier dans l’éditeur, mais ne considérez pas encore le conflit comme terminé. La modification du contenu et la déclaration à Git que le fichier est résolu sont deux étapes distinctes. La prochaine leçon vous montrera comment contrôler le résultat, préparer le fichier et poursuivre ou annuler le rebase selon la situation.

À retenir

• Comparez la base commune et les deux versions avant de modifier le fichier.
• Lors d’un rebase, interprétez les côtés du conflit selon l’opération en cours, pas selon une intuition liée à votre branche.
• Préservez les changements compatibles et tranchez explicitement les variantes incompatibles.
• Supprimez tous les marqueurs et vérifiez la cohérence du contenu final avant de poursuivre.