Jusqu'ici, l'information n'a circulé que dans un sens : de votre ordinateur vers GitHub, avec git push. Ce guide s'occupe du sens inverse. Il distingue deux commandes souvent confondues : git fetch, qui regarde ce qui a changé côté distant, et git pull, qui va plus loin en intégrant directement ce changement dans votre branche locale.

Provoquer un changement distant

Pour rendre la différence concrète, modifiez mon-premier-site directement depuis GitHub, sans passer par votre terminal. Rendez-vous sur la page du dépôt dans votre navigateur, ouvrez README.md, cliquez sur le bouton d'édition (une icône en forme de crayon), puis ajoutez une ligne, par exemple une mention de l'auteur du projet. Validez la modification avec le bouton de commit proposé par l'interface GitHub, directement sur la branche main.

Un nouveau commit vient d'être créé, mais uniquement sur GitHub. Retournez maintenant dans le dossier mon-premier-site original sur votre ordinateur, celui que vous utilisez depuis le début de ce parcours, pas le clone du guide précédent.

git fetch : regarder sans toucher

Cette commande télécharge les nouveaux commits distants, ici celui créé depuis GitHub, mais ne modifie aucun fichier de votre dossier de travail. Vérifiez-le avec git status :

Git vous informe que votre branche locale a pris du retard d'un commit par rapport à origin/main, mais il ne l'a pas comblé automatiquement. Vous pouvez inspecter ce nouveau commit avant de décider quoi que ce soit, par exemple avec git log origin/main --oneline -n 3, ce qui vous laisse le temps de vérifier ce qu'il contient sans engager votre branche locale.

git pull : récupérer puis intégrer

Une fois que vous avez décidé d'intégrer ce commit, git pull fait en une commande ce que git fetch puis une fusion (ou un rebase, selon la configuration du dépôt) auraient fait en deux étapes.

Cette fois, README.md a bien été mis à jour sur votre disque : ouvrez-le pour confirmer que la ligne ajoutée depuis GitHub apparaît. Vous reconnaissez au passage le mot « Fast-forward », déjà rencontré au guide 11 sur la fusion : c'est exactement le même mécanisme, appliqué ici entre votre branche locale et origin/main plutôt qu'entre deux branches locales.

Quand utiliser fetch, quand utiliser pull

Utilisez git fetch quand vous voulez simplement savoir si quelque chose a changé côté distant, avant de décider comment réagir, en particulier si vous avez vous-même des modifications locales en cours que vous ne voulez pas mélanger tout de suite. Utilisez git pull quand vous êtes prêt à intégrer immédiatement ces changements, typiquement en début de séance de travail, avant de commencer vos propres modifications.

Bon réflexe

Avant de commencer une nouvelle session de travail sur un projet relié à GitHub, en particulier si quelqu'un d'autre peut y contribuer, lancez un git pull en tout début, sur un dossier de travail propre. Vous évitez ainsi de découvrir une divergence plus tard, au moment justement où vous voudrez pousser votre propre travail.

Et si ce n'est pas un simple avancement ?

Si vous avez vous-même créé un commit local que vous n'avez pas encore poussé, au moment où vous lancez git pull, Git peut avoir besoin de combiner votre commit local et le commit distant, exactement comme lors d'une fusion entre deux branches. Si les deux commits touchent la même zone d'un même fichier, un conflit peut apparaître : vous savez déjà, depuis le guide 12, exactement comment le lire et le résoudre.

Vérifiez que vous avez compris

Vous venez de lancer git fetch origin, et le terminal indique qu'un nouveau commit a été récupéré. Vous ouvrez immédiatement index.html dans votre éditeur, sans avoir tapé git pull. Le contenu affiché a-t-il changé ?

Non. git fetch télécharge l'information sur les nouveaux commits distants, mais ne touche à aucun fichier de votre dossier de travail. Tant que vous n'avez pas explicitement demandé une intégration, par exemple avec git pull ou une fusion manuelle, vos fichiers restent strictement identiques à avant la commande.

Chapitre terminé