Comment vérifier si un fichier a des conflits dans Git

Introduction

Dans ce laboratoire (lab), vous apprendrez à identifier et à comprendre les conflits de fusion (merge conflicts) dans Git. Nous allons simuler un scénario de conflit en apportant des modifications conflictuelles au même fichier dans différentes branches, puis en tentant de les fusionner (merge).

Vous utiliserez la commande git status pour détecter la présence de conflits, puis vous examinerez le fichier en conflit pour voir les marqueurs de conflit que Git insère. Enfin, vous vérifierez que les fichiers sans conflit ne sont pas marqués comme tels.

Skills Graph

Exécuter git status pour détecter les conflits

Dans cette étape, nous allons apprendre à utiliser la commande git status pour détecter les conflits dans votre dépôt Git. Les conflits se produisent lorsque deux modifications différentes sont apportées à la même partie d'un fichier, et Git ne sait pas quelle modification conserver.

Tout d'abord, assurons-nous que nous sommes dans le répertoire de notre projet. Ouvrez votre terminal et accédez au répertoire my-time-machine :

cd ~/project/my-time-machine

Maintenant, simulons un conflit. Imaginez que vous et un collaborateur ayez tous les deux apporté des modifications au fichier message.txt en même temps, mais dans des branches différentes. Pour ce laboratoire (lab), nous allons créer manuellement un scénario qui entraîne un conflit.

Tout d'abord, créons une nouvelle branche et apportons une modification.

git branch feature/greeting
git checkout feature/greeting
echo "Hope you are doing well!" >> message.txt
git add message.txt
git commit -m "Add a greeting"

Maintenant, revenons à la branche master et apportons une modification différente au même fichier.

git checkout master
echo "This is an important message." >> message.txt
git add message.txt
git commit -m "Add an important message"

Nous avons maintenant deux modifications différentes apportées au fichier message.txt dans deux branches différentes. Lorsque nous essayons de fusionner (merge) ces branches, Git détectera un conflit.

Essayons de fusionner la branche feature/greeting dans la branche master :

git merge feature/greeting

Vous devriez voir un message indiquant un conflit :

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

Ce message nous indique qu'il y a un conflit de fusion (merge conflict) dans le fichier message.txt. Git n'a pas été en mesure de fusionner automatiquement les modifications car elles se chevauchent.

Maintenant, exécutons la commande git status pour voir comment Git signale le conflit :

git status

La sortie ressemblera à ceci :

On branch master
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 resolve merge conflicts)
        both modified:   message.txt

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

La sortie de git status montre clairement que nous sommes "On branch master" et que nous avons des "unmerged paths". Elle liste également le fichier message.txt sous "Unmerged paths" et indique qu'il a été "both modified". C'est ainsi que git status vous aide à identifier les fichiers qui ont des conflits de fusion.

Comprendre comment utiliser git status pour détecter les conflits est la première étape pour les résoudre. Dans les étapes suivantes, nous apprendrons à examiner le fichier en conflit et à résoudre le conflit.

Vérifier le fichier pour les marqueurs de conflit

Dans l'étape précédente, nous avons vu que git status signalait un conflit dans le fichier message.txt. Maintenant, examinons le fichier lui-même pour voir comment Git marque les sections conflictuelles.

Assurez-vous que vous êtes toujours dans le répertoire ~/project/my-time-machine.

Nous pouvons utiliser la commande cat pour afficher le contenu du fichier :

cat message.txt

La sortie ressemblera à ceci :

Hello, Future Me
<<<<<<< HEAD
This is an important message.
=======
Hope you are doing well!
>>>>>>> feature/greeting

Remarquez les marqueurs spéciaux que Git a ajoutés au fichier :

• <<<<<<< HEAD : Cela marque le début des modifications dans la branche actuelle (qui est HEAD, pointant vers master dans ce cas).
• ======= : C'est un séparateur entre les modifications des deux branches.
• >>>>>>> feature/greeting : Cela marque la fin des modifications de la branche à partir de laquelle vous effectuez la fusion (merge) (feature/greeting).

Ces marqueurs vous montrent exactement où le conflit s'est produit et quelles sont les différentes versions des lignes conflictuelles. Les lignes entre <<<<<<< HEAD et ======= sont les modifications de votre branche actuelle (master), et les lignes entre ======= et >>>>>>> feature/greeting sont les modifications de la branche que vous fusionnez (feature/greeting).

Votre tâche maintenant est d'éditer manuellement ce fichier et de décider quelles modifications conserver. Vous devez supprimer les marqueurs de conflit et les lignes que vous ne voulez pas conserver, en laissant uniquement le contenu final souhaité.

Par exemple, si vous vouliez conserver les deux messages, vous éditeriez le fichier pour qu'il ressemble à ceci :

Hello, Future Me
This is an important message.
Hope you are doing well!

Ou, si vous ne vouliez conserver que le message de la branche master, vous éditeriez le fichier pour qu'il ressemble à ceci :

Hello, Future Me
This is an important message.

Utilisez l'éditeur nano pour ouvrir et éditer le fichier message.txt :

nano message.txt

Editez le fichier pour résoudre le conflit en supprimant les marqueurs de conflit et en choisissant le contenu que vous voulez conserver. Pour ce laboratoire (lab), conservons les deux messages.

Après l'édition, le contenu du fichier devrait être :

Hello, Future Me
This is an important message.
Hope you are doing well!

Appuyez sur Ctrl + X pour quitter nano, puis appuyez sur Y pour enregistrer les modifications, et enfin appuyez sur Enter pour confirmer le nom du fichier.

En éditant manuellement le fichier et en supprimant les marqueurs de conflit, vous indiquez à Git comment combiner les modifications conflictuelles. C'est une étape cruciale dans la résolution des conflits de fusion (merge conflicts).

Tester les fichiers sans conflit

Dans les étapes précédentes, nous avons identifié et examiné un fichier avec un conflit de fusion (merge conflict) (message.txt). Cependant, lors d'une fusion (merge), il peut également y avoir des fichiers qui ont été modifiés dans les deux branches mais sans conflit. Git fusionne automatiquement ces fichiers.

Dans cette étape, nous allons créer un nouveau fichier dans l'une des branches et voir comment Git le gère lors du processus de fusion. Cela nous aidera à comprendre que les conflits ne se produisent que lorsque les modifications se chevauchent dans le même fichier.

Assurez-vous que vous êtes toujours dans le répertoire ~/project/my-time-machine et sur la branche master (où le conflit de fusion s'est produit).

Créons un nouveau fichier appelé notes.txt dans la branche master :

echo "Important notes for the project." > notes.txt
git add notes.txt
git commit -m "Add project notes"

Maintenant, revenons à la branche feature/greeting :

git checkout feature/greeting

Dans cette branche, le fichier notes.txt n'existe pas encore. Créons un fichier différent ici, par exemple, todo.txt :

echo "Things to do: finish the lab." > todo.txt
git add todo.txt
git commit -m "Add a todo list"

Maintenant, revenons à la branche master et tentons la fusion à nouveau. Même si nous avons déjà résolu le conflit dans message.txt, le processus de fusion doit être terminé.

git checkout master
git merge feature/greeting

Cette fois-ci, puisque nous avons déjà résolu le conflit dans message.txt et l'avons ajouté à la zone de préparation (staging area) (bien que nous n'ayons pas explicitement montré cette étape après l'édition, Git met souvent le fichier en attente après la résolution manuelle du conflit), Git devrait être en mesure de terminer la fusion. Vous pourriez voir un message indiquant que la fusion est terminée.

Vérifions à nouveau l'état (status) :

git status

La sortie devrait maintenant indiquer que vous êtes "On branch master" et que l'arbre de travail (working tree) est propre, ce qui signifie qu'il n'y a pas de modifications en attente ou de chemins non fusionnés.

On branch master
nothing to commit, working tree clean

Maintenant, vérifions si les fichiers des deux branches sont présents dans la branche master :

ls

Vous devriez voir à la fois message.txt, notes.txt (de la branche master) et todo.txt (de la branche feature/greeting) répertoriés.

message.txt  notes.txt  todo.txt

Cela démontre que Git a réussi à fusionner les modifications de feature/greeting, y compris le nouveau fichier todo.txt, sans aucun conflit car todo.txt n'existait pas dans la branche master. Les conflits ne se produisent que lorsque le même fichier a des modifications chevaucheantes dans les branches en cours de fusion.

Comprendre comment Git gère à la fois les fichiers conflictuels et non conflictuels lors d'une fusion est essentiel pour gérer efficacement l'historique de votre projet.

Résumé

Dans ce laboratoire (lab), nous avons appris à détecter les conflits dans Git en utilisant la commande git status. Nous avons simulé un conflit en apportant des modifications différentes au même fichier dans des branches distinctes, puis en tentant de les fusionner (merge). La sortie de la commande git status a clairement indiqué la présence de chemins non fusionnés et le fichier spécifique présentant le conflit.

Nous avons également exploré comment identifier les marqueurs de conflit à l'intérieur du fichier en conflit lui - même, que Git insère pour mettre en évidence les sections conflictuelles. Enfin, nous avons confirmé que les fichiers sans conflit ne sont pas marqués avec ces caractères spéciaux, renforçant ainsi notre compréhension de la façon dont Git signale les problèmes de fusion (merge issues).