Polarys
Git et versioning : les bases/Réparer ses erreurs

Réparer ses erreurs

Résoudre un conflit de fusion

Un conflit n'est pas une panne

Un conflit survient quand deux personnes ont modifié les mêmes lignes d'un même fichier. Git sait fusionner des modifications éloignées ; il refuse de choisir à votre place quand elles se superposent.

C'est une protection. Un outil qui trancherait tout seul produirait silencieusement du code faux.

Ce que Git écrit dans le fichier

<<<<<<< HEAD
timeout = 30
=======
timeout = 60
>>>>>>> branche-collegue

Trois repères : au-dessus du =======, votre version, celle de la branche sur laquelle vous êtes. En dessous, la version qui arrive. Les marqueurs eux-mêmes doivent disparaître du fichier final : les laisser est l'erreur classique, et elle casse le fichier.

La marche à suivre

git status                    # liste les fichiers en conflit
# éditer chaque fichier, choisir, supprimer les marqueurs
git add fichier-resolu.yml
git commit                    # message de fusion pré-rempli

Et si vous voulez abandonner et repartir de zéro :

git merge --abort

Cette commande remet tout dans l'état d'avant la fusion. Elle est sans risque, et elle vaut mieux qu'une résolution faite dans la précipitation.

Résoudre ne veut pas dire choisir un camp

L'erreur la plus fréquente est de garder mécaniquement sa propre version parce qu'on la connaît. Un conflit signale que deux personnes ont eu une intention sur le même point, et la bonne résolution intègre souvent les deux.

Dans l'exemple ci-dessus, la vraie question n'est pas « 30 ou 60 » mais « pourquoi le collègue l'a-t-il augmenté ». S'il l'a fait parce qu'un traitement dépassait la limite, écraser sa valeur réintroduit son incident.

Quand le doute persiste, demandez. Trente secondes de conversation contre une régression discrète.

Après la résolution

Relisez le fichier entier, pas seulement la zone du conflit. Une fusion mal résolue produit souvent un fichier syntaxiquement correct et logiquement absurde, avec une clé en double ou un bloc orphelin.

Et testez avant de pousser. Un conflit résolu et non testé est la source classique du commit qui casse la branche principale, celui que tout le monde remarque.

Comment en avoir moins

Trois habitudes suffisent à faire chuter le nombre de conflits :

  • des branches courtes, fusionnées en quelques jours plutôt qu'en quelques semaines
  • récupérer souvent la branche principale dans la sienne, plutôt qu'une seule fois à la fin
  • des commits ciblés, qui ne mélangent pas une reformulation générale et un changement de fond

La branche qui vit trois semaines produit un conflit proportionnel à son âge.

À retenir

Un conflit est une question posée, pas une erreur. Supprimez les marqueurs, comprenez l'intention de l'autre version avant de trancher, relisez tout le fichier et testez. Des branches courtes et des mises à jour fréquentes valent mieux que n'importe quelle technique de résolution.

Quiz de validation

Quiz - 3 questions

1. Que représente la partie située au-dessus de la ligne de séparation dans un conflit ?

2. Vous voulez abandonner une fusion en cours et repartir de l'état précédent. Quelle commande ?

3. Quelle habitude réduit le plus le nombre de conflits ?

Suis ta progression

Crée un compte gratuit pour suivre ta progression et accéder à toutes les leçons.