Résoudre les conflits de fusion

Au chapitre 4, Git fusionnait tout seul. Mais parfois, il s'arrête et te demande de l'aide : c'est un conflit. Bonne nouvelle : c'est normal, ça arrive à tout le monde, et ça se résout toujours avec la même méthode.

À la fin de ce chapitre, tu sauras :

• ●Expliquer pourquoi un conflit arrive
• ●Repérer les fichiers en conflit avec git status
• ●Lire les marqueurs de conflit dans un fichier
• ●Choisir la bonne version : la tienne, l'autre ou un mélange
• ●Terminer la fusion avec git add et git commit
• ●Annuler une fusion avec git merge --abort

Imagine un document partagé. Toi et un collègue modifiez la même phrase en même temps. Le logiciel ne peut pas deviner laquelle garder : il vous demande de décider.

Un conflit n'est pas une erreur, et rien n'est cassé. C'est Git qui te dit : « je ne peux pas décider à ta place ».

Prenons un exemple concret avec mon-portfolio :

Git te prévient tout de suite :

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Première étape : savoir quels fichiers sont concernés. Ton réflexe, git status :

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

Les fichiers en conflit sont dans la section Unmerged paths, avec la mention both modified (modifié des deux côtés). Ici, un seul fichier : index.html.

Ouvre le fichier en conflit dans ton éditeur. Git y a ajouté des marqueurs qui montrent les deux versions, l'une au-dessus de l'autre :

<<<<<<< HEAD
<h1>Bonjour</h1>
=======
<h1>Welcome</h1>
>>>>>>> feature/header

• ●<<<<<<< HEAD : le début du conflit. Juste en dessous, ta version, celle de la branche où tu es (ici main).
• ●======= : la séparation entre les deux versions.
• ●>>>>>>> feature/header : la fin du conflit. Juste au-dessus, la version de l'autre branche, dont le nom est indiqué.

Résoudre un conflit, c'est écrire la version finale du passage. Tu as trois options :

• ●Garder ta version (celle du haut) : tu supprimes la version du bas.
• ●Garder l'autre version (celle du bas) : tu supprimes la version du haut.
• ●Combiner les deux : tu écris un mélange, par exemple <h1>Bonjour et welcome</h1>.

Dans tous les cas, tu supprimes aussi les trois lignes de marqueurs. Par exemple, si tu gardes ta version, le passage devient :

<h1>Bonjour</h1>

Quand tous les marqueurs ont disparu du fichier, dis à Git que le conflit est résolu avec git add, puis termine la fusion avec un commit :

[main 4e9a1c7] Fusionner feature/header en gardant le titre Bonjour

Vérifie que tout est en ordre :

On branch main
nothing to commit, working tree clean

Tu es perdu au milieu d'un conflit, ou tu veux d'abord en parler à ton équipe ? Tu peux tout annuler :

Ton dépôt revient exactement à l'état d'avant le git merge. Rien n'est perdu, ni de ton côté ni de l'autre. Tu pourras relancer la fusion quand tu seras prêt.

Les conflits sont normaux, mais quelques habitudes les rendent plus rares et plus petits :

• ●Fais git pull souvent : tu travailles sur la version la plus récente.
• ●Fusionne souvent : une branche qui vit trois semaines s’éloigne beaucoup plus de main qu’une branche qui vit deux jours.
• ●Fais des petits commits ciblés : moins de lignes touchées, moins de risques de collision.
• ●Parle avec ton équipe : si vous devez modifier le même fichier, organisez-vous.
• ●Découpe ton code en petits fichiers : deux personnes ont moins de chances de toucher le même.

Ton aide-mémoire du chapitre :

• ●Laisser des marqueurs <<<<<<< dans le code : le fichier ne fonctionne plus. Cherche <<<<<<< dans tes fichiers avant de commiter.
• ●Faire git add sans relire le fichier : vérifie que le résultat est bien celui que tu veux.
• ●Effacer le travail de l'autre sans le comprendre : lis les deux versions, et demande si besoin.
• ●Oublier un fichier : tant qu'un fichier reste dans Unmerged paths, Git refuse le commit. Relance git status.
• ●Faire git merge --abort à chaque fois par peur : savoir annuler est utile, mais résoudre un conflit est une compétence qui s’apprend vite.

Comment Git sait-il qu’il y a un conflit ? Il ne compare pas deux versions du fichier, mais trois :

• ●La version de ta branche (HEAD)
• ●La version de l'autre branche
• ●La version de l'ancêtre commun : le dernier commit que les deux branches partagent, avant de se séparer

Si une ligne n'a changé que d'un côté par rapport à l'ancêtre, Git prend ce changement sans hésiter. Si elle a changé des deux côtés, de façon différente, c'est un conflit. On appelle ça une fusion à trois points (three-way merge).

Tu peux retrouver l'ancêtre commun de deux branches :

3f2a1b4c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a

Dernier quiz du parcours : vérifie que tu sais résoudre un conflit. Clique sur la réponse qui te semble correcte : chaque réponse est expliquée.