Résolution des Conflits de Fusion Git Courants : Un Guide de Dépannage Étape par Étape

Un conflit de fusion Git signifie que Git a trouvé des modifications qui se chevauchent et a besoin que vous choisissiez la version finale. Vous verrez généralement cela lorsque deux branches ont modifié les mêmes lignes, renommé le même fichier différemment, ou ont toutes deux édité un fichier que Git ne peut pas fusionner automatiquement.

L'objectif est simple : inspecter le conflit, éditer le fichier à la version que vous souhaitez réellement, le mettre en scène, puis continuer la fusion ou le rebase.

Comprendre ce qu'est un Conflit de Fusion Git

Un conflit de fusion se produit lorsque Git tente d'intégrer les modifications d'une branche dans une autre (par exemple, en utilisant git merge ou git rebase), mais constate que les deux branches ont modifié indépendamment les mêmes lignes du même fichier. Git est excellent pour combiner les modifications non chevauchantes, mais nécessite une intervention humaine lorsque les modifications se chevauchent directement.

Comment Git Signale un Conflit

Lorsqu'un conflit survient pendant une fusion, Git arrête immédiatement l'opération et vous notifie que la fusion a échoué. Les fichiers affectés seront marqués comme en conflit dans votre répertoire de travail. Vous pouvez vérifier l'état en utilisant :

git status

La sortie listera les fichiers "Chemins non fusionnés", indiquant qu'ils nécessitent une résolution manuelle avant que la fusion puisse continuer.

Étape 1 : Identifier les Marqueurs de Conflit

Une fois que Git a arrêté la fusion, les fichiers en conflit contiennent des marqueurs spéciaux insérés par Git pour délimiter les sections en conflit. Ces marqueurs vous aident à voir exactement quelles modifications proviennent de quelle branche.

Les marqueurs de conflit

Dans un conflit de texte normal, vous verrez trois lignes de marqueurs entourant deux versions du contenu :

<<<<<<< HEAD :
- Marque le début des modifications de la branche courante (la branche dans laquelle vous fusionnez).
======= :
- Agit comme un séparateur entre les deux ensembles de modifications conflictuelles.
>>>>>>> nom-de-branche :
- Marque la fin des modifications de la branche entrante (la branche à partir de laquelle vous fusionnez).

Exemple d'un Bloc de Conflit :

Supposons que vous fusionnez fonctionnalité/A dans main, et que les deux branches ont modifié la ligne 10 de config.js :

// config.js

function getTimeout() {
<<<<<<< HEAD
  return 5000; // Valeur par défaut de la branche main
=======
  return 10000; // Remplacement de la fonctionnalité A
>>>>>>> fonctionnalité/A
}

Étape 2 : Résoudre le Conflit en Éditant le Fichier

Résoudre le conflit implique d'éditer le fichier pour supprimer les marqueurs Git et sélectionner la combinaison de code souhaitée. Vous avez trois stratégies de résolution principales :

A. Conserver les Modifications de HEAD (Branche Courante)

Si vous décidez que la version de votre branche courante (HEAD) est correcte, vous supprimez les modifications entrantes et tous les marqueurs.

Action de Résolution :

// config.js

function getTimeout() {
  return 5000; // Valeur par défaut de la branche main
}

B. Conserver les Modifications de la Branche Entrante

Si vous décidez que les modifications de la branche en cours de fusion sont correctes, vous supprimez les modifications de la branche courante et tous les marqueurs.

Action de Résolution :

// config.js

function getTimeout() {
  return 10000; // Remplacement de la fonctionnalité A
}

C. Combiner ou Réécrire les Modifications (L'Approche Hybride)

Souvent, la meilleure solution est de construire manuellement une nouvelle version qui incorpore la logique des deux côtés, ou de réécrire entièrement le code pour satisfaire aux exigences des deux modifications originales.

Action de Résolution (Exemple Hybride) :

// config.js

function getTimeout() {
  // Définir le délai d'attente en fonction de la variable d'environnement, combinant la logique
  if (process.env.NODE_ENV === 'production') {
      return 10000;
  }
  return 5000; 
}

Meilleure Pratique : Vérifiez toujours que le code résultant compile et fonctionne correctement après avoir résolu un bloc de conflit. L'exécution de tests unitaires est fortement recommandée à ce stade.

Étape 3 : Mettre en Scène les Fichiers Résolus

Après avoir manuellement édité chaque fichier en conflit, en supprimant tous les marqueurs <<<<<<<, =======, et >>>>>>>, vous devez mettre ces modifications en scène pour informer Git que le conflit a été traité.

Utilisez la commande standard git add pour chaque fichier que vous avez résolu :

git add config.js
git add src/utils/helper.py
# ... répétez pour tous les fichiers en conflit

Pour vérifier que Git reconnaît la résolution, exécutez git status à nouveau. Tous les chemins précédemment non fusionnés devraient maintenant apparaître sous "Modifications qui seront validées".

Étape 4 : Terminer la Fusion ou le Rebase

Une fois que tous les conflits sont mis en scène, vous finalisez l'opération en fonction de la commande initiale lancée :

Terminer un `git merge`

Si vous effectuiez une fusion standard, vous la finalisez avec un commit :

git commit

Git ouvrira généralement votre éditeur de texte configuré avec un message de commit de fusion pré-rempli. Examinez-le, enregistrez-le et fermez l'éditeur. La fusion est maintenant terminée.

Terminer un `git rebase`

Si vous effectuiez un rebase, vous continuez le processus, qui applique les commits suivants sur l'état résolu :

git rebase --continue

Si les commits suivants dans la séquence de rebase provoquent également des conflits, vous répétez les étapes 2 à 4 pour chaque conflit rencontré.

Conseils de Dépannage pour les Conflits Difficiles

Bien que les étapes ci-dessus couvrent la résolution standard, des scénarios complexes peuvent nécessiter des approches alternatives :

Abandonner l'opération

Si vous démarrez une fusion ou un rebase et réalisez que la situation est trop complexe ou que vous devez consulter un coéquipier, vous pouvez toujours revenir à l'état antérieur à l'émission de la commande :

git merge --abort  # Si vous avez commencé avec 'git merge'
git rebase --abort  # Si vous avez commencé avec 'git rebase'

Utiliser un outil de diff visuel

Pour les fichiers complexes avec de nombreuses modifications qui se chevauchent, l'utilisation d'un outil de fusion à trois voies dédié (comme l'éditeur de fusion intégré de VS Code, KDiff3 ou Meld) est fortement recommandée. Vous pouvez lancer votre outil configuré directement :

git mergetool

Cette interface montre souvent la version locale, la version distante et l'ancêtre commun de base, rendant la sélection manuelle beaucoup plus claire.

Gérer les fichiers binaires

Git ne peut pas fusionner automatiquement les fichiers binaires (comme les images ou les ressources compilées). Si deux branches modifient le même fichier binaire, Git signalera un conflit. Dans ce cas, vous devez choisir manuellement quelle version conserver en copiant le fichier préféré dans le répertoire de travail, en le mettant en scène, et en validant/continuant.

# Pendant une fusion, conserver la version de votre branche courante
git checkout --ours image.png

# Ou conserver la version de la branche en cours de fusion
git checkout --theirs image.png

git add image.png
git commit

Pendant un rebase, --ours et --theirs peuvent sembler inversés car Git rejoue les commits sur une nouvelle base. Exécutez git status, inspectez le fichier et confirmez la version choisie avant de la mettre en scène.

À Retenir

N'essayez pas de "supprimer le conflit" en effaçant aveuglément les marqueurs. Lisez les deux côtés, décidez ce que le code final devrait être, exécutez les tests pertinents, puis mettez en scène les fichiers résolus. Après cela, utilisez git commit pour une fusion ou git rebase --continue pour un rebase.