Introduction

git fetch télécharge de nouveaux objets et met à jour les refs de tracking distant sans modifier votre arborescence de travail. git pull fait un fetch puis intègre le résultat dans votre branche courante. Connaître la différence est l'un des plus grands pas du novice à l'utilisateur Git confiant.

Fetcher

git fetch                  # remote par défaut (généralement origin)
git fetch origin
git fetch --all
git fetch --prune          # supprimer les refs des branches supprimées sur le serveur
git fetch origin main      # une seule branche

Après un fetch, inspectez ce qui a changé :

git log HEAD..origin/main --oneline
git diff HEAD origin/main

Puller

git pull est un raccourci pour fetch suivi soit d'un merge soit d'un rebase. Choisissez la stratégie :

git pull                          # utilise la config pull.rebase
git pull --rebase
git pull --ff-only                # refuse si pas fast-forward
git pull origin main

Configurer le comportement par défaut

git config --global pull.rebase false   # merge (défaut classique)
git config --global pull.rebase true    # rebase
git config --global pull.ff only        # fast-forward seulement
git config --global fetch.prune true

Depuis Git 2.27, un git pull nu avertit si aucune stratégie n'est configurée.

Fetch ou pull, lequel utiliser

• Utilisez fetch quand vous voulez regarder avant d'intégrer.
• Utilisez pull --ff-only quand vous voulez simplement vous mettre à jour sur une branche partagée.
• Utilisez pull --rebase quand vous travaillez sur une branche thématique non poussée.
• Évitez pull simple sur des branches partagées de longue durée ; les merge commits se multiplient.

Inspecter l'upstream

git status
# On branch main
# Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.

Ce message provient de la comparaison de HEAD au origin/main mis en cache ; exécutez git fetch d'abord pour le rendre exact.

Récupérer des pull requests

La plupart des hôtes Git exposent les branches de pull request ou merge request comme des refs spéciales que vous pouvez fetcher dans votre clone pour revue. Pour GitHub, ajoutez un refspec :

git config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*'
git fetch
git switch -c review/123 origin/pr/123

Pour GitLab le chemin équivalent est refs/merge-requests/*/head. Avec cela configuré, chaque git fetch récupère toutes les PR ouvertes localement, prêtes pour inspection sans quitter votre terminal.

Erreurs fréquentes

Exécuter git pull avec des changements non commités et obtenir un merge commit inattendu par-dessus du travail sale. Stashez ou commitez d'abord. Oublier que le compteur « behind » de git status n'est aussi frais que le dernier fetch ; si personne n'a fetché depuis une semaine, ce compteur ment. Utiliser git pull --rebase sur une branche sur laquelle d'autres ont basé leur travail réécrit leur base ; rebasez seulement sur des branches privées. Enfin, n'utilisez jamais git fetch <refspec> avec un refspec personnalisé sans le comprendre ; un deux-points accidentel (main:main) écrase votre main local.