Introduction

Git est un système de contrôle de version distribué : chaque clone est un dépôt complet avec son propre historique intégral, et non une simple copie de travail extraite d'un serveur central. C'est pourquoi la collaboration dans Git se résume essentiellement à de la synchronisation — partager des branches entières entre dépôts plutôt que d'échanger un simple ensemble de modifications.

Cette page présente les quatre commandes qui déplacent des commits entre votre dépôt local et les dépôts distants : git remote, git fetch, git push et git pull. Chaque commande est détaillée sur sa propre page, mais comprendre comment elles s'articulent est ce qui rend la collaboration au quotidien prévisible.

Le modèle mental : local vs. distant

Avant d'aborder les commandes individuelles, il est utile d'avoir une image simple en tête. Trois éléments entrent en jeu lors d'une synchronisation :

• Votre dépôt local — les branches sur lesquelles vous commitez, par exemple main.
• Un remote — un signet nommé (tel que origin) qui pointe vers l'URL d'un autre dépôt.
• Les branches de suivi distant — des copies locales en lecture seule des branches du remote, nommées comme origin/main. Elles enregistrent où se trouvait le remote la dernière fois que vous avez communiqué avec lui.

La direction du flux de données vous indique quelle commande utiliser :

• git fetch et git pull rapatrient des commits depuis le remote.
• git push envoie des commits vers le remote.
• git remote gère les connexions elles-mêmes.

git remote

La commande git remote est conçue pour créer, afficher et supprimer des connexions vers d'autres dépôts. Par défaut, elle liste toutes les connexions distantes qui ont été enregistrées précédemment.

Lorsque vous clonez un dépôt, Git crée automatiquement un remote appelé origin pointant vers l'URL source, de sorte que vous en ajoutez rarement un manuellement pour vos propres projets. Vous ajoutez des remotes supplémentaires lorsque vous collaborez via des forks, par exemple en faisant pointer upstream vers le projet original dont vous avez forké.

# List configured remotes
git remote
# origin

# Show their fetch/push URLs
git remote -v
# origin  https://github.com/user/repo.git (fetch)
# origin  https://github.com/user/repo.git (push)

# Add a second remote
git remote add upstream https://github.com/original/repo.git

git fetch

La commande git fetch télécharge des commits, des fichiers et des références depuis un dépôt distant vers votre dépôt local, en mettant à jour vos branches de suivi distant (comme origin/main). Elle vous permet de voir ce sur quoi les autres membres de l'équipe ont travaillé sans toucher à votre branche de travail.

git fetch et git pull téléchargent tous deux du contenu depuis le remote, mais git fetch est l'option sûre et non destructive : elle fait uniquement avancer les branches de suivi distant et ne modifie jamais vos fichiers de travail. Rien n'est fusionné tant que vous ne le demandez pas explicitement.

# Download new commits from origin (does not change your working branch)
git fetch origin

# Review what arrived before integrating it
git log main..origin/main

# Integrate it yourself when ready
git merge origin/main

Ce modèle « fetch, puis révision, puis merge » explique pourquoi de nombreuses équipes préfèrent git fetch à git pull : vous pouvez inspecter les modifications entrantes avant qu'elles n'atterrissent sur la branche que vous êtes en train de modifier.

git push

La commande git push téléverse le contenu de votre dépôt local vers un dépôt distant. Là où git fetch importe des commits dans vos branches de suivi distant locales, git push exporte vos commits locaux vers les branches correspondantes sur le remote, afin que le reste de l'équipe puisse les voir.

# Push the current branch's commits to origin
git push origin main

# First push of a new branch: set up tracking with -u
git push -u origin feature-login

Un push ne réussit que lorsqu'il peut faire avancer la branche distante sans perdre de commits (un fast-forward). Si quelqu'un d'autre a pushé entre-temps, Git rejette le push et vous demande d'intégrer son travail en premier, généralement en exécutant git pull ou git fetch suivi d'un merge. Évitez --force sur les branches partagées : cela peut écraser les commits de vos coéquipiers.

git pull

La commande git pull est essentiellement git fetch suivi d'une étape d'intégration, le tout en une seule commande. Elle télécharge le nouveau contenu depuis le remote et l'intègre immédiatement dans votre branche courante.

Par défaut, git pull combine git fetch avec git merge, créant un commit de merge lorsque les historiques ont divergé. Vous pouvez le configurer pour utiliser git rebase à la place (git pull --rebase), ce qui rejoue vos commits locaux par-dessus les commits récupérés pour obtenir un historique linéaire.

# Fetch from origin and merge into the current branch
git pull origin main

# Fetch and rebase your local commits on top instead
git pull --rebase origin main

Quand utiliser laquelle

Un guide de décision rapide pour le travail quotidien :

• Vous commencez votre journée de travail ? Exécutez git pull (ou git fetch + révision + merge) pour récupérer les dernières modifications.
• Vous voulez voir ce qui a changé sans perturber votre travail ? Utilisez git fetch, puis git log ou git diff par rapport à origin/<branch>.
• Vous avez terminé une partie du travail ? Exécutez git push pour la partager.
• Le push a été rejeté ? Le remote a des commits que vous n'avez pas. Faites un pull (ou un fetch puis un merge/rebase), résolvez les éventuels conflits, puis pushez à nouveau.

À partir de là, consultez les pages dédiées à chaque commande et lisez le chapitre sur les workflows Git pour voir comment les équipes combinent ces commandes en un processus reproductible.

Practice