git pull

Ce que fait git pull

git pull télécharge les nouveaux commits depuis un dépôt distant et les intègre immédiatement dans votre branche locale actuelle. C'est la commande que vous exécutez pour mettre votre travail à jour avec ce que vos coéquipiers ont poussé.

En coulisses, git pull est un raccourci pratique pour deux commandes exécutées l'une après l'autre :

git fetch <remote>          # download the new commits
git merge <remote>/<branch> # integrate them into the current branch

Ainsi, git pull équivaut à git fetch suivi de git merge. Comprendre cette division est la clé pour comprendre toute la commande : fetch met à jour vos branches de suivi distantes sans toucher à votre travail, et merge (ou rebase, voir ci-dessous) rejoue le nouvel historique sur votre branche.

Quand l'utiliser

git pull fait partie du workflow de "synchronisation" de Git, aux côtés de git push, git fetch et git remote. Utilisez-la chaque fois que vous souhaitez que votre branche locale reflète le dernier état distant, par exemple :

• Avant de commencer un nouveau travail, afin de construire sur la base du code le plus récent.
• Avant d'exécuter git push, pour que votre push avance en fast-forward plutôt que d'être rejeté comme "non-fast-forward".
• Pour récupérer les commits d'un coéquipier sur une branche partagée.

git fetch et git pull téléchargent tous deux du contenu distant, mais ils diffèrent sur un point important : git fetch met uniquement à jour vos branches de suivi distantes et laisse votre copie de travail intacte, tandis que git pull fusionne également ces changements dans votre branche actuelle. Si vous souhaitez inspecter les commits entrants avant de les intégrer, faites d'abord un fetch puis fusionnez vous-même.

Comment fonctionne la fusion lors d'un pull

Supposons que votre branche locale et la branche distante partagent un historique jusqu'au commit E, puis divergent. Le dépôt distant a obtenu les commits A, B et C que vous n'avez pas. Exécuter git pull récupère ces commits.

Git crée ensuite un nouveau commit de fusion, H, qui relie votre travail local aux commits récupérés A, B et C, combinant les deux lignes d'historique.

Si votre branche locale n'a pas divergé (vous n'avez aucun nouveau commit local), Git déplace simplement le pointeur de votre branche vers les nouveaux commits. Cela s'appelle un fast-forward et ne produit aucun commit de fusion.

Avec l'option --rebase, Git rejoue vos commits locaux par-dessus les commits récupérés au lieu de créer un commit de fusion, ce qui maintient un historique linéaire.

Options courantes

Exemples

Tirer depuis la branche amont

Invoquer git pull sans argument récupère et fusionne les changements depuis la branche amont configurée pour la branche actuelle :

git pull

Pour que cela fonctionne, la branche actuelle doit avoir un amont défini (Git le stocke après le premier git push -u ou git branch --set-upstream-to).

Tirer depuis un remote et une branche spécifiques

Vous pouvez nommer le remote et la branche explicitement :

git pull <remote> <branch>

Cela récupère et fusionne les changements depuis la branche spécifiée du remote nommé. Par exemple, pour tirer la branche develop depuis le remote origin :

git pull origin develop

Tirer avec rebase

git pull --rebase

Au lieu de fusionner, cette commande rejoue vos commits locaux par-dessus les commits récupérés. Le résultat est un historique linéaire sans commit de fusion, que de nombreuses équipes préfèrent pour les branches de fonctionnalités. Pour en faire le comportement par défaut d'une branche, configurez git config pull.rebase true. Consultez git rebase pour les compromis à considérer.

Tirer sans valider la fusion

git pull --no-commit

Cette commande récupère et fusionne mais s'arrête juste avant de créer le commit de fusion, laissant le résultat en zone de staging pour que vous puissiez le réviser (et l'amender) avant de valider avec git commit.

Résoudre les conflits après un pull

Si les commits distants ont modifié les mêmes lignes que vous avez modifiées localement, la fusion ne peut pas se terminer automatiquement et Git signale un conflit :

Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts and then commit the result.

Pour le résoudre, ouvrez chaque fichier en conflit, modifiez-le pour conserver le contenu correct (en supprimant les marqueurs <<<<<<<, ======= et >>>>>>>), puis préparez et validez :

git add app.js
git commit

Si vous préférez ne pas traiter le conflit maintenant, git merge --abort ramène votre branche à son état avant le pull.

Pratique