GIT - 21 Résolution des conflits
Dans cette leçon, nous allons provoquer délibérément un conflit de merge, puis le résoudre proprement. Je suis dans le repository test, sur la branche master, working directory propre. L'idée : modifier la même partie du même fichier (coucou.html) sur deux branches différentes, puis tenter de les fusionner.
Étape 1 — Créer un conflit
Créons une branche jordan-test et modifions coucou.html dessus :
git checkout -b jordan-test
# édition d'une ligne dans coucou.html
git commit -am "mauvaise update"
Revenons sur master et modifions la même ligne du même fichier, puis committons :
git checkout master
# édition de la même ligne dans coucou.html
git commit -am "mauvaise update encore"
Étape 2 — Tenter le merge
git merge jordan-test
Git nous prévient : la fusion automatique a échoué, il y a un conflit dans coucou.html. L'invite de commande passe en mode merge avec le nom de la branche entre crochets. Si on ouvre le fichier, on voit des marqueurs spéciaux :
<<<<<<< HEAD
ligne version master
=======
ligne version jordan-test
>>>>>>> jordan-test
Étape 3 — Résoudre avec mergetool
Bien qu'on puisse éditer manuellement, l'outil graphique configuré (P4Merge ici) facilite grandement le travail :
git mergetool
- P4Merge ouvre une vue à trois panneaux (master, jordan-test, résultat fusionné)
- Sélectionnez la version souhaitée (ou éditez à la main)
- Sauvegardez et fermez l'outil
Une fois la résolution sauvegardée, le mode merge est terminé. Finalisez le merge avec un commit :
git commit -m "conflit résolu"
P4Merge laisse des fichiers temporaires .orig qui peuvent traîner dans le repository. Ajoutez-les à .gitignore avec le motif *.orig, puis supprimez ceux déjà présents avec rm.
En résumé
Cette leçon démontre comment Git détecte et signale les conflits lors d'une fusion de branches. Le conflit survient quand deux branches modifient les mêmes portions d'un fichier : la fusion automatique échoue et Git laisse l'utilisateur dans un état MERGING jusqu'à résolution. L'outil git mergetool affiche les versions concurrentes et permet de choisir celle à conserver ou de fusionner manuellement. Une fois résolu, un commit final conclut la fusion et remet le repository en état normal.
Points clés
- Un conflit survient quand deux branches modifient identiquement un fichier : Git ne sait pas quelle version privilégier
- La commande git merge échoue et place le dépôt en état MERGING (visible dans l'invite de commande)
- Les marqueurs de conflit (<<<<<<< HEAD, =======, >>>>>>>) délimitent les portions en conflit dans le fichier
- git mergetool lance un outil de fusion graphique pour comparer les trois versions (courante, fusion, autre branche)
- Après résolution manuelle et sauvegarde, git commit -m "Conflict resolved" finalise la fusion
- Les fichiers temporaires (.orig) générés par mergetool doivent être ajoutés à .gitignore pour éviter de les versionner accidentellement
Questions fréquentes
Qu'est-ce qu'un conflit Git et quand se produit-il ?
Un conflit survient quand deux branches modifient les mêmes lignes d'un fichier. Lors du git merge, l'outil ne sait pas quelle version appliquer et s'arrête, laissant l'utilisateur en état MERGING pour trancher manuellement.
Comment résoudre un conflit avec git mergetool ?
La commande git mergetool ouvre une interface graphique affichant trois colonnes : la version courante (HEAD), la version de l'autre branche, et la fusion proposée. L'utilisateur choisit quelle version valider, puis sauvegarde pour finaliser la résolution.
Pourquoi faut-il ajouter les fichiers .orig à .gitignore ?
Lors de la fusion, git mergetool génère des fichiers .orig (copie du fichier original avant modification). Sans .gitignore, ces fichiers temporaires risquent d'être accidentellement commités dans le repository.