Introduction

git pull est du sucre pour git fetch suivi de l'intégration de la branche upstream dans la branche courante. L'étape d'intégration est soit un merge (par défaut) soit un rebase.

Les deux étapes

1. git fetch <remote> <refspec> : télécharge et met à jour les refs de tracking.
2. Si pull.rebase est false : git merge FETCH_HEAD.
3. Si pull.rebase est true : git rebase FETCH_HEAD.

Séquence manuelle équivalente :

git fetch origin main
git merge origin/main             # ou git rebase origin/main

Configuration

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, sinon abandonner

Depuis Git 2.27, un simple git pull sans configuration affiche un avertissement. Choisissez une stratégie explicitement.

Fast-forward seulement

--ff-only est le pull le plus sûr : il ne réussit que si votre branche est strictement en retard. Pas de merge commit, pas de rebase, pas de surprises.

git pull --ff-only

Combinez avec autostash pour éviter les blocages d'arborescence de travail :

git pull --ff-only --autostash

Pull avec rebase

git pull --rebase
git pull --rebase=merges          # préserver la structure de merge

--rebase=merges est utile pour les branches qui contiennent des merge commits que vous voulez garder.

Pull avec autostash

git config --global rebase.autoStash true
git config --global merge.autoStash true

Avec ces options activées, les arborescences sales sont stashées avant l'intégration et réappliquées après, de façon transparente.

Pull multi-branches

git pull origin main feature        # fetche les deux, merge octopus dans HEAD

C'est rarement ce que vous voulez ; préférez des opérations séparées.

Pull vs fetch + intégration explicite

De nombreux utilisateurs expérimentés préfèrent ne jamais utiliser git pull. Ils exécutent git fetch d'abord, inspectent git log HEAD..@{u}, puis choisissent merge ou rebase délibérément. C'est particulièrement précieux lors de l'intégration de branches divergentes de longue durée.

Politiques de pull pour les équipes

Les équipes saines choisissent une seule politique de pull et la configurent à l'échelle de l'organisation. Deux choix courants :

# Équipe historique linéaire : rebase au pull, merge via PR seulement
git config --global pull.rebase true
git config --global rebase.autoStash true

# Équipe favorable au merge : jamais rebase, toujours fast-forward main
git config --global pull.rebase false
git config --global pull.ff only

La pire configuration est l'absente : le git pull de chaque développeur se comporte différemment, produisant des historiques incohérents. Documentez la politique dans le CONTRIBUTING.md de votre dépôt et fournissez un snippet de configuration en une ligne que les nouveaux contributeurs peuvent copier.

Erreurs fréquentes

Exécuter git pull avec des changements non commités et obtenir un merge commit inattendu par-dessus du travail sale. Soit stashez, commitez ou définissez autoStash. Puller avec rebase sur une branche sur laquelle d'autres ont basé leur travail ; vous réécrivez leur base. Rebasez seulement sur des branches privées. Configurer pull.rebase globalement sans réaliser que cela affecte aussi main ; de nombreuses équipes définissent pull.ff only globalement et surchargent par branche. Enfin, utiliser git pull en CI ; la CI a rarement besoin d'intégration, seulement du dernier commit. Utilisez git fetch et un checkout explicite de origin/main pour garder la CI déterministe.