Comment vérifier si un commit Git est un commit de fusion

Introduction

Dans ce laboratoire (lab), vous apprendrez à déterminer si un commit Git est un commit de fusion (merge commit). Nous allons explorer la commande git show pour examiner les détails d'un commit, en particulier en nous concentrant sur l'identification des commits parents, qui est un indicateur clé d'une fusion.

Vous apprendrez également à utiliser la commande git log --merges pour lister efficacement uniquement les commits de fusion dans l'historique de votre dépôt. Enfin, nous testerons ces méthodes sur des commits qui ne sont pas des fusions pour consolider votre compréhension de la façon de distinguer les différents types de commits dans Git.

Skills Graph

Utiliser git show pour vérifier les commits parents

Dans cette étape, nous allons explorer comment utiliser la commande git show pour examiner les détails d'un commit, en particulier en nous concentrant sur ses commits parents. Comprendre les commits parents est essentiel pour naviguer dans l'historique de votre projet et comprendre comment les différents commits sont liés les uns aux autres.

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, utilisons git log pour voir l'historique de nos commits. Nous utiliserons le drapeau --oneline pour avoir une vue concise :

git log --oneline

Vous devriez voir une sortie similaire à celle-ci (votre hachage de commit sera différent) :

a1b2c3d (HEAD -> master) Send a message to the future

Cela montre notre premier commit. Maintenant, utilisons git show pour voir les détails de ce commit. Copiez le hachage de commit (la courte chaîne de lettres et de chiffres, comme a1b2c3d) de la sortie de votre commande git log et remplacez YOUR_COMMIT_HASH dans la commande ci-dessous :

git show YOUR_COMMIT_HASH

Par exemple, si votre hachage de commit était a1b2c3d, vous exécuteriez :

git show a1b2c3d

La sortie sera assez détaillée, affichant des informations sur le commit, y compris l'auteur, la date, le message de commit et les modifications introduites par le commit.

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Jane Doe <[email protected]>
Date:   Mon Aug 7 10:00:00 2023 +0000

    Send a message to the future

diff --git a/message.txt b/message.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/message.txt
@@ -0,0 +1 @@
+Hello, Future Me

Pour notre premier commit, qui est le tout début de l'historique de notre projet, vous remarquerez qu'il n'y a pas de ligne "Parent" dans la sortie. C'est parce que le commit initial n'a pas de parent – c'est la racine de l'historique du projet.

Dans les étapes suivantes, lorsque nous aurons plus de commits, nous utiliserons à nouveau git show pour voir comment les commits parents sont affichés et comment ils relient l'historique ensemble. Comprendre ce lien est fondamental pour comprendre comment Git suit les modifications au fil du temps.

Exécuter git log --merges pour vérifier

Dans cette étape, nous allons apprendre à propos des commits de fusion (merge commits) et à utiliser la commande git log --merges pour afficher spécifiquement uniquement ce type de commits dans l'historique de notre projet. Les commits de fusion sont des commits spéciaux qui rassemblent les modifications de différentes branches.

Actuellement, l'historique de notre projet est très simple, avec seulement un commit initial. Nous n'avons pas encore de branches ni de fusions. Vérifions d'abord cela en exécutant la commande git log --merges.

Assurez-vous d'être dans le répertoire ~/project/my-time-machine :

cd ~/project/my-time-machine

Maintenant, exécutez la commande :

git log --merges

Étant donné que nous n'avons effectué aucune fusion, cette commande ne produira probablement aucun résultat :

C'est normal ! La commande git log --merges est conçue pour filtrer l'historique des commits et n'afficher que les commits créés suite à la fusion d'une branche dans une autre.

Pour voir cette commande en action, nous devrions créer une nouvelle branche, effectuer quelques commits sur cette branche, puis la fusionner de nouveau dans notre branche principale. Nous explorerons la création de branches et les fusions dans des laboratoires (labs) ultérieurs.

Pour l'instant, il est important de comprendre que git log --merges est un outil puissant pour comprendre quand et comment différentes lignes de développement ont été combinées dans votre projet. Cela est particulièrement utile dans des environnements collaboratifs où plusieurs personnes travaillent simultanément sur différentes fonctionnalités.

Tester les commits non de fusion

Dans cette étape, nous allons créer un commit classique (un commit non de fusion) puis utiliser git log pour voir comment il apparaît dans notre historique par rapport à un commit de fusion (que nous n'avons pas encore, mais aurons dans des labs ultérieurs). Cela vous aidera à mieux comprendre les différents types de commits.

Tout d'abord, apportons une petite modification à notre fichier message.txt. Nous allons ajouter une autre ligne.

Assurez-vous d'être dans le répertoire ~/project/my-time-machine :

cd ~/project/my-time-machine

Maintenant, utilisez la commande echo pour ajouter une nouvelle ligne au fichier :

echo "Adding another line." >> message.txt

L'opérateur >> ajoute le texte au fichier au lieu de le remplacer.

Vérifions le contenu du fichier :

cat message.txt

Vous devriez voir :

Hello, Future Me
Adding another line.

Maintenant, vérifions l'état de notre dépôt :

git status

Vous devriez voir que message.txt a été modifié :

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   message.txt

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

Git a détecté la modification que nous avons apportée. Maintenant, préparons (stage) et validons (commit) cette modification.

git add message.txt
git commit -m "Add a second line to message"

Vous devriez voir une sortie confirmant le commit :

[master a1b2c3d] Add a second line to message
 1 file changed, 1 insertion(+)

Maintenant, regardons à nouveau notre historique de commits en utilisant git log --oneline :

git log --oneline

Vous devriez voir deux commits :

e4f5g6h (HEAD -> master) Add a second line to message
a1b2c3d Send a message to the future

Le dernier commit (e4f5g6h dans cet exemple, votre hachage sera différent) est notre nouveau commit non de fusion. Il représente une seule modification apportée directement sur la branche master.

Si nous devions exécuter à nouveau git log --merges, il n'afficherait toujours aucun résultat car aucun de ces commits n'est un commit de fusion.

Comprendre la différence entre les commits classiques et les commits de fusion est important pour interpréter l'historique de votre projet et collaborer efficacement avec les autres. Les commits classiques représentent une progression linéaire sur une seule ligne de développement, tandis que les commits de fusion représentent l'intégration de modifications provenant de différentes lignes.

Résumé

Dans ce laboratoire (lab), nous avons appris à identifier les commits de fusion (merge commits) dans Git. Nous avons commencé par utiliser la commande git show pour examiner les détails d'un commit, en nous concentrant particulièrement sur la présence ou l'absence de commits parents. Nous avons vu que le commit initial n'a pas de parent, tandis que les commits suivants affichent leur(s) parent(s).

Ensuite, nous avons exploré la commande git log --merges, qui est un moyen direct de lister uniquement les commits de fusion dans l'historique du dépôt. Enfin, nous avons testé ces méthodes sur des commits non de fusion pour confirmer qu'ils sont correctement identifiés comme tels, renforçant ainsi notre compréhension de la façon de distinguer les commits de fusion des commits classiques.