Git remote : guide complet avec exemples

Découvrez les remotes Git, leur rôle et comment les utiliser pour le contrôle de version de votre projet. Avec des exemples pratiques.

Actualisé 19 sept. 2026 · 11 min lire

Explorer avec l’IA

ChatGPT Claude Perplexity

Git est un système de contrôle de version (VCS) très répandu en développement logiciel, conçu pour suivre l’évolution des fichiers dans le temps. Il facilite la collaboration en permettant à plusieurs développeurs de travailler en parallèle sans écraser le travail des autres. Comme chacun dispose d’une copie locale complète de l’historique du projet, il est possible de travailler hors ligne en toute autonomie et de fusionner ses changements en toute sécurité une fois prêt.

Un dépôt distant, ou remote, est une version de votre projet Git hébergée dans le cloud via un service en ligne comme GitHub ou BitBucket.

Cet article détaille le fonctionnement des remotes Git. Si vous débutez avec Git, commencez par notre tutoriel Git pour débutants.

Qu’est-ce qu’un remote Git ?

Un remote Git offre un emplacement centralisé où un dépôt peut être stocké, partagé et accédé par d’autres. Les utilisateurs peuvent pousser leurs modifications locales vers le remote et récupérer (pull) les mises à jour des coéquipiers. Les remotes servent également de sauvegarde et peuvent être utilisés pour déployer du code en production.

Un dépôt local vit sur votre ordinateur : vous y éditez le code, créez des commits et testez vos changements en local. Un dépôt distant, hébergé en ligne, sert à partager le code, collaborer et sauvegarder votre travail. Dans cet article, nous verrons comment synchroniser les changements entre dépôts locaux et distants à l’aide des commandes Git.

Flux de travail Git

Un flux de travail classique commence par le « clonage » d’un dépôt distant sur votre machine. Après clonage, vous pouvez créer une branche pour développer une fonctionnalité ou corriger un bug, apporter des modifications et les valider (commit) en local.

Quand votre travail est prêt, vous « poussez » la branche vers le remote et ouvrez une pull request pour relecture. Une fois approuvée, fusionnez les changements dans la branche principale.

Tout au long du processus, vous effectuez régulièrement des « pull » pour garder votre dépôt local synchronisé avec le distant.

Un flux de travail Git typique (image tirée du cours Introduction to Git)

Voyons ce processus plus en détail.

Cloner un dépôt

Supposons que vous souhaitiez copier un dépôt distant : on parle de « cloner » le dépôt. Avec une copie locale, vous pouvez modifier le code et tester de nouvelles fonctionnalités.

Pour utiliser Git, assurez-vous qu’il est installé, puis ouvrez un terminal et exécutez : git clone <URL>.

Par exemple, pour cloner un projet nommé « project » depuis la page GitHub de l’utilisateur « datacamp », utilisez

git clone https://github.com/datacamp/project.git

Remote par défaut : « origin »

Quand vous clonez un dépôt, Git crée un remote par défaut nommé origin. Ce libellé origin agit comme un alias de l’URL du dépôt que vous avez cloné.

Dans les workflows Git habituels, lorsque vous lancez des commandes comme git push ou git pull, Git suppose que vous faites référence à origin sauf indication contraire. Cela simplifie la synchronisation entre votre copie locale et le dépôt partagé. Nous reviendrons plus loin sur push et pull.

Gérer les remotes Git

Parmi les opérations courantes : visualiser les remotes existants avec git remote et ajouter un nouveau remote avec git remote add.

Afficher les remotes configurés

Pour voir les remotes existants, utilisez la commande git remote.

git remote
>> origin

Dans notre exemple, l’alias origin est listé, mais sans son URL. Pour afficher l’URL associée à chaque remote, ajoutez l’option -v.

git remote -v
>> origin	https://github.com/datacamp/project.git (fetch)
>> origin	https://github.com/datacamp/project.git (push)

Ajouter un nouveau remote

Vous pouvez souhaiter relier votre dépôt local à un autre remote. Par exemple, si vous avez forké un projet, vous voudrez suivre les changements du dépôt original en plus de ceux de votre remote main. Ou bien pousser votre code vers plusieurs plateformes, comme GitHub et GitLab.

Pour ajouter un remote, utilisez git remote add <name> <URL>. Ajoutons un remote nommé new_remote.

git remote add new_remote https://github.com/datacamp/project

Nommer le remote évite d’avoir à retaper l’URL à chaque fusion.

Renommer et supprimer des remotes

Renommer un remote est simple : git remote rename <old-name> <new-name>. Par exemple :

git remote rename new_remote original_remote

Pour vérifier le renommage, listez les remotes avec git remote.

Pour supprimer un remote, utilisez git remote remove <name>. Dans notre exemple :

git remote remove new_remote

Listez à nouveau les remotes pour vérifier.

git remote
>> origin

On constate qu’il ne reste que origin.

Travailler avec des branches distantes

Une branche dans Git est une voie de développement indépendante de main qui permet de travailler à part de la version principale du projet. Une fois votre travail terminé et relu, vous pouvez fusionner la branche dans le projet principal.

Lister les branches distantes

Pour lister les branches distantes, utilisez git branch -r.

git branch -r
>> origin/HEAD -> origin/main
>> origin/main

Interprétons la sortie : la ligne origin/main indique qu’il existe une branche distante nommée main sur le remote origin. La ligne origin/HEAD -> origin/main montre que la branche par défaut du remote est origin/main. Autrement dit, main est la branche par défaut sur origin et c’est la seule branche distante listée.

Suivre une branche distante

Vous souhaiterez souvent lier une branche locale à une branche distante pour garder votre code synchronisé. Lorsqu’une branche locale suit une branche distante, vous pouvez pull/push sans spécifier systématiquement le remote et le nom de branche.

Git suit aussi combien de commits votre branche locale a d’avance ou de retard par rapport au distant, ce qui facilite la gestion des changements.

La commande git checkout --track origin/<branch-name> crée une branche locale qui suit la branche distante indiquée. Elle crée une branche locale du même nom que <branch-name> et l’associe à sa version distante. Dès lors, git pull et git push opèrent automatiquement sur la bonne branche distante. Pour en savoir plus sur Git Push et Pull, consultez notre tutoriel.

Récupérer et tirer depuis les remotes

Pour rester aligné avec les changements des autres, vous devez ramener le contenu dans votre branche locale. « Pull » signifie télécharger les derniers changements depuis la branche correspondante sur le remote et les fusionner dans votre branche locale. Vous travaillez ainsi sur la version la plus à jour du code.

Supposons que nous voulions récupérer toutes les branches du remote origin. Utilisez git fetch origin. Pour ne récupérer qu’une branche spécifique, par exemple main, précisez-la : git fetch origin main.

Après un fetch, vous devez encore synchroniser en fusionnant les changements récupérés dans votre branche locale active : git merge origin/<branch-name>, en remplaçant <branch-name> par la branche concernée. Par exemple, pour fusionner les changements de main distante : git merge origin/main.

Comme il est fréquent d’enchaîner fetch puis merge, Git fournit une commande qui fait les deux : git pull. Par exemple, pour récupérer et fusionner les changements de la branche main sur le remote origin, utilisez git pull origin main.

Quand privilégier fetch + merge et quand utiliser pull ? Le processus en deux étapes vous laisse plus de contrôle. Fetch permet de voir ce qui a changé sur le remote avant de fusionner en local : utile pour revoir les mises à jour, comparer les différences ou gérer des conflits potentiels avec soin.

Utilisez pull lorsque vous avez confiance dans les changements distants et souhaitez mettre à jour rapidement votre branche. C’est pratique car tout est réuni en une seule commande, mais vous avez moins de visibilité avant la fusion.

Pousser vers un dépôt distant

« Pousser » des contenus depuis une branche locale vers un remote signifie envoyer vos modifications locales vers la branche correspondante du dépôt distant. Le remote est alors mis à jour avec votre dernier travail pour que chacun puisse le voir, le pull ou le prolonger. Le push partage vos contributions et maintient le dépôt distant à jour pour toute l’équipe.

L’envoi de modifications locales vers le remote se fait en trois étapes.

1. Utilisez git add pour sélectionner (stager) les fichiers à inclure. Pour ajouter tous les changements, utilisez

git add

Pour ajouter un fichier spécifique, indiquez son nom.

git add <filename>

2. Validez vos changements (commit) avec un message décrivant ce que vous avez fait.

git commit -m “Your commit message here”

3. Poussez vers le remote.

git push origin branch-name

Exemples pratiques

Voyons quelques scénarios : cloner un dépôt et collaborer avec plusieurs remotes.

Cloner un dépôt

Guide pas à pas pour cloner un dépôt :

Récupérer l’URL du dépôt. Copiez l’URL du dépôt à cloner. Elle est fournie par votre service d’hébergement (GitHub, BitBucket, etc.).
Choisir un répertoire. Placez-vous dans le dossier où vous souhaitez copier le dépôt.
Cloner le dépôt. Exécutez git clone <URL>. Par exemple, lancez git clone https://github.com/datacamp/project.Une nouvelle archive nommée project est créée avec le contenu du dépôt.
Lister les remotes configurés. Après clonage, vérifiez les remotes avec git remote.Dans notre exemple, vous verrez origin, nom par défaut attribué par Git au remote d’origine, ainsi que son URL.

Collaborer avec plusieurs remotes

Dans les projets open source ou via un fork personnel, il est courant d’utiliser deux remotes : origin (votre fork) et upstream (le dépôt d’origine). En général, vous avez les droits d’écriture sur origin, mais pas sur upstream.

Voici quelques bonnes pratiques à retenir pour gérer plusieurs remotes.

Ajouter le remote upstream. Après avoir cloné votre fork, suivez le dépôt original en tant qu’upstream : git remote add upstream <URL>.
Garder votre fork à jour. Récupérez régulièrement les changements depuis upstream avec git fetch upstream, puis fusionnez ou rebasez ces changements dans votre branche locale.
Ne poussez pas vers le dépôt upstream. Vous n’avez généralement pas (ou pas besoin) d’accès en écriture à upstream. Poussez tous vos changements sur origin et ouvrez vos pull requests depuis celui-ci.
Utiliser des noms de branches explicites. Gardez vos branches locales organisées : nommez-les selon la fonctionnalité ou le ticket traité.
Vérifier vos remotes. Utilisez git remote -v pour contrôler votre configuration et valider les URLs de origin et upstream.
Se synchroniser avant de travailler. Avant de commencer une nouvelle tâche, tirez systématiquement les derniers changements depuis upstream dans votre branche principale pour rester à jour et éviter les conflits.

Bonnes pratiques et astuces pour Git remote

Voici quelques bonnes pratiques à suivre avec les remotes Git :

Garder les remotes à jour

Récupérer régulièrement les changements garantit que votre copie locale reste alignée avec le dépôt distant. Avec git fetch, vous téléchargez les nouveautés sans impacter votre branche courante.

Vous suivez ainsi ce que vos collègues ont poussé, comparez les changements et préparez les mises à jour ou fusions nécessaires. Des fetchs réguliers réduisent les risques de conflits et fluidifient la collaboration.

Avec le temps, certaines branches supprimées sur le dépôt distant peuvent encore apparaître en local en tant que branches de suivi distantes « périmées ».

Pour faire le ménage, exécutez git remote prune origin afin de supprimer les références qui n’existent plus sur le remote origin.

Cette opération, réalisée régulièrement, garde votre dépôt local propre, facilite la recherche des branches utiles et évite de se baser sur des travaux obsolètes.

Gérer les conflits avec les remotes

Les conflits distants peuvent être délicats à résoudre. Le mieux est de les prévenir : évitez que plusieurs personnes travaillent simultanément sur les mêmes zones du code. Ce n’est toutefois pas toujours possible.

Malgré tout, des conflits peuvent survenir. Voici une démarche efficace pour les gérer.

Utilisez git status pour identifier les fichiers en conflit.
Ouvrez les fichiers concernés et résolvez les différences.
Servez-vous d’un outil de merge. Des outils comme VS Code ou git mergetool affichent les versions côte à côte et facilitent le choix des lignes à conserver.
Communiquez avec l’équipe. En cas de doute, échangez avec vos collègues avant de trancher.
Testez votre code après résolution afin de valider le bon fonctionnement.
Validez (commit) vos corrections : stagez les fichiers puis créez le commit de fusion.

Rebase

Utiliser git pull --rebase peut réduire le risque de conflits complexes en appliquant vos commits au-dessus des derniers commits distants.

Avec git pull --rebase, Git commence par récupérer les dernières modifications, puis rejoue vos commits locaux par-dessus, comme s’ils étaient intervenus après.

Cette approche offre un historique plus linéaire et propre, et limite les fusions « bruitées ».

Au lieu de créer un commit de merge qui combine les historiques, le rebase fait comme si vos changements étaient postérieurs aux mises à jour distantes. Pour aller plus loin, consultez notre tutoriel Git Rebase.

Conclusion

Les remotes Git sont essentiels à la collaboration : ils relient vos dépôts locaux à des bases de code partagées. Dans ce guide, nous avons vu les opérations clés : configuration, synchronisation via fetch, pull et push, et gestion de plusieurs connexions distantes.

Maîtriser ces notions vous aide à collaborer plus efficacement, garder un historique clair et apporter de meilleures contributions à votre équipe de développement.

Pour aller plus loin sur les branches distantes, découvrez les ressources DataCamp.