Comment vérifier si un dépôt distant Git a de nouveaux commits

Introduction

Dans ce laboratoire (lab), vous apprendrez à vérifier si un dépôt distant Git contient de nouveaux commits qui ne sont pas encore présents dans votre dépôt local. Cette compétence est essentielle pour le développement collaboratif, car elle vous permet de rester à jour avec les modifications apportées par les autres.

Nous commencerons par simuler un dépôt distant et l'ajouter à notre projet local. Ensuite, nous utiliserons la commande git fetch pour récupérer des informations sur les branches et les commits du dépôt distant sans les fusionner. Enfin, nous explorerons comment comparer votre branche locale avec sa contrepartie en amont pour identifier tout nouveau commit sur le dépôt distant.

Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/DataManagementGroup(["Data Management"]) git(("Git")) -.-> git/BranchManagementGroup(["Branch Management"]) git(("Git")) -.-> git/CollaborationandSharingGroup(["Collaboration and Sharing"]) git/DataManagementGroup -.-> git/reset("Undo Changes") git/BranchManagementGroup -.-> git/log("Show Commits") git/CollaborationandSharingGroup -.-> git/fetch("Download Updates") git/CollaborationandSharingGroup -.-> git/pull("Update & Merge") git/CollaborationandSharingGroup -.-> git/remote("Manage Remotes") subgraph Lab Skills git/reset -.-> lab-560074{{"Comment vérifier si un dépôt distant Git a de nouveaux commits"}} git/log -.-> lab-560074{{"Comment vérifier si un dépôt distant Git a de nouveaux commits"}} git/fetch -.-> lab-560074{{"Comment vérifier si un dépôt distant Git a de nouveaux commits"}} git/pull -.-> lab-560074{{"Comment vérifier si un dépôt distant Git a de nouveaux commits"}} git/remote -.-> lab-560074{{"Comment vérifier si un dépôt distant Git a de nouveaux commits"}} end

Récupérer les modifications distantes avec git fetch

Dans cette étape, nous allons apprendre à récupérer les modifications depuis un dépôt distant. Imaginez que vous travaillez sur un projet avec d'autres personnes et qu'elles ont apporté des mises à jour. Vous devez récupérer ces mises à jour sur votre machine locale. La commande git fetch vous permet de le faire. Elle télécharge les dernières modifications depuis un dépôt distant sans les fusionner dans votre branche actuelle.

Tout d'abord, simulons avoir un dépôt distant. Nous allons créer un dépôt nu (bare repository) puis l'ajouter en tant que dépôt distant à notre dépôt existant my-time-machine.

cd ~/project
mkdir remote-repo.git
cd remote-repo.git
git init --bare

Cela crée un dépôt Git nu, qui est généralement utilisé comme dépôt central à partir duquel les développeurs poussent (push) et tirent (pull) les modifications.

Maintenant, revenons à notre dépôt my-time-machine et ajoutons ce dépôt nu en tant que dépôt distant.

cd ~/project/my-time-machine
git remote add origin ~/project/remote-repo.git

Nous avons nommé notre dépôt distant origin, ce qui est une convention courante. Vérifions maintenant que le dépôt distant a été ajouté correctement.

git remote -v

Vous devriez voir une sortie similaire à celle-ci, montrant les URL de récupération (fetch) et d'envoi (push) pour le dépôt distant origin :

origin	/home/labex/project/remote-repo.git (fetch)
origin	/home/labex/project/remote-repo.git (push)

Maintenant, simulons une modification dans le dépôt distant. Comme il s'agit d'un dépôt nu, nous ne pouvons pas directement effectuer des commits dedans. Au lieu de cela, nous allons simuler une modification en créant un nouveau fichier dans le répertoire du dépôt nu.

cd ~/project/remote-repo.git
echo "This is a remote change" > remote_file.txt

Maintenant, revenons à votre dépôt my-time-machine.

cd ~/project/my-time-machine

À ce stade, votre dépôt local ne sait rien du fichier remote_file.txt qui a été ajouté au dépôt distant simulé. C'est là que la commande git fetch entre en jeu.

Exécutez la commande git fetch :

git fetch origin

Vous pourriez ne pas voir beaucoup de sortie, ou vous pourriez voir quelque chose indiquant que de nouveaux objets ont été reçus.

Ce que git fetch origin a fait, c'est de se connecter au dépôt distant origin et de télécharger tous les nouveaux commits et objets qui ne sont pas dans votre dépôt local. Cependant, il n'a pas fusionné ces modifications dans votre branche actuelle (master). Les modifications sont maintenant disponibles dans votre dépôt local, mais elles sont stockées dans une branche spéciale qui suit le dépôt distant, généralement nommée origin/master.

Voici une différence clé entre git fetch et git pull. git pull est essentiellement git fetch suivi d'une fusion. En utilisant d'abord git fetch, vous pouvez voir quelles modifications sont disponibles sur le dépôt distant avant de décider de les intégrer à votre travail. Cela vous donne plus de contrôle et vous aide à éviter les conflits inattendus.

Dans l'étape suivante, nous verrons comment comparer votre branche locale avec la branche distante récupérée pour comprendre quelles modifications ont été téléchargées.

Exécuter git log HEAD..@{u}

Dans l'étape précédente, nous avons utilisé git fetch pour télécharger les modifications depuis le dépôt distant. Maintenant, voyons comment nous pouvons afficher les commits qui sont sur le dépôt distant mais pas encore dans notre branche locale. C'est là que la commande git log HEAD..@{u} est très utile.

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

cd ~/project/my-time-machine

Maintenant, exécutez la commande suivante :

git log HEAD..@{u}

Vous pourriez voir une sortie similaire à celle-ci :

commit abcdef1234567890abcdef1234567890abcdef (origin/master)
Author: Simulated User <[email protected]>
Date:   Mon Aug 7 10:05:00 2023 +0000

    Simulated remote commit

Décortiquons cette commande :

git log : C'est la commande pour afficher l'historique des commits.
HEAD : Cela fait référence au commit vers lequel votre branche actuelle pointe.
@{u} : C'est un raccourci pour la branche en amont (upstream branch). Dans notre cas, puisque nous avons récupéré (fetch) depuis origin et que notre branche locale master suit origin/master, @{u} fait référence à origin/master.
HEAD..@{u} : C'est une notation de plage dans Git. Cela signifie "montre-moi les commits qui sont accessibles depuis @{u} mais pas accessibles depuis HEAD". En termes plus simples, cela vous montre les commits qui sont sur la branche de suivi distante (origin/master) mais qui ne sont pas sur votre branche locale actuelle (master).

Cette commande est incroyablement utile pour voir quelles modifications vous obtiendriez si vous fusionniez (merge) ou rebasiez (rebase) votre branche locale avec la branche de suivi distante. Elle vous permet de passer en revue les modifications à venir avant de les intégrer, ce qui est une partie cruciale d'un flux de travail sûr et contrôlé.

Vous vous demandez peut-être : "Comment Git a-t-il su parler du commit distant simulé ?" Lorsque nous avons exécuté git fetch origin dans l'étape précédente, Git a téléchargé les informations sur les commits dans le dépôt origin, y compris le commit qui a introduit remote_file.txt. Ces informations sont stockées dans la branche de suivi origin/master de votre dépôt local. La commande git log HEAD..@{u} compare ensuite votre branche locale master (HEAD) avec cette branche de suivi origin/master (@{u}) pour vous montrer la différence.

Appuyez sur q pour quitter la vue du journal (log) si elle est en mode plein écran.

Comprendre la différence entre votre branche locale et la branche de suivi distante est fondamental pour travailler efficacement avec des dépôts distants. Cette commande offre un moyen clair de visualiser ces différences.

Tester les dépôts distants synchronisés

Dans les étapes précédentes, nous avons récupéré les modifications depuis un dépôt distant simulé et appris à afficher les commits qui sont sur le dépôt distant mais pas dans notre branche locale en utilisant git log HEAD..@{u}. Maintenant, voyons ce qui se passe lorsque notre branche locale est à jour avec la branche de suivi distante.

Tout d'abord, simulons la fusion des modifications distantes dans notre branche locale. Alors que git fetch ne télécharge que les modifications, git pull télécharge puis fusionne. Dans le cadre de ce test, nous allons simuler l'état après un pull en mettant manuellement à jour notre branche locale pour qu'elle corresponde à la branche de suivi distante.

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

cd ~/project/my-time-machine

Maintenant, simulons la fusion en réinitialisant notre branche locale master au même commit que origin/master. Remarque : Dans un scénario réel, vous utiliseriez généralement git merge origin/master ou git pull origin master pour intégrer les modifications. Nous utilisons git reset --hard ici uniquement à des fins de démonstration pour synchroniser rapidement notre branche locale avec la branche de suivi distante pour le test.

git reset --hard origin/master

Vous devriez voir une sortie indiquant que votre branche a été mise à jour et que l'arbre de travail est propre.

HEAD is now at abcdef1 Simulated remote commit

Maintenant que notre branche locale master est synchronisée avec origin/master, exécutons à nouveau la commande git log HEAD..@{u}.

git log HEAD..@{u}

Cette fois, vous ne devriez voir aucune sortie.

Pourquoi aucune sortie ? Parce que HEAD (notre branche locale master) et @{u} (la branche de suivi origin/master) pointent maintenant vers le même commit. La plage HEAD..@{u} est vide car il n'y a pas de commits accessibles depuis @{u} qui ne soient pas également accessibles depuis HEAD.

C'est le comportement attendu lorsque votre branche locale est entièrement synchronisée avec sa branche de suivi distante en amont. La commande git log HEAD..@{u} est un moyen rapide de vérifier s'il y a des modifications à venir du dépôt distant que vous n'avez pas encore intégrées. Si la commande ne montre aucune sortie, cela signifie que votre branche locale est à jour avec la branche de suivi distante.

Comprendre comment vérifier les modifications à venir et comment interpréter la sortie de git log HEAD..@{u} est essentiel pour collaborer avec d'autres personnes et maintenir votre dépôt local synchronisé avec le dépôt distant.

Résumé

Dans ce laboratoire (lab), nous avons appris à vérifier si un dépôt distant Git a de nouveaux commits. Nous avons commencé par comprendre le but de git fetch, qui télécharge les modifications depuis un dépôt distant sans les fusionner. Nous avons simulé un dépôt distant en créant un dépôt Git nu (bare repository) et en l'ajoutant en tant que dépôt distant nommé origin à notre dépôt local my-time-machine. Nous avons vérifié la configuration du dépôt distant en utilisant git remote -v.

Ensuite, nous avons simulé une modification dans le dépôt distant en créant un fichier directement dans le répertoire du dépôt nu. Nous avons ensuite utilisé la commande git fetch origin pour récupérer ces modifications dans notre dépôt local, nous préparant ainsi à vérifier la présence de nouveaux commits.