Pour faciliter le travail depuis plusieurs machines ou en équipe, Git permet d'utiliser des dépôts locaux ou distants. Dans ce second cas, on parle de « remotes ». S'il est courant d'en utiliser un seul à la fois, ce n'est pas une limite inscrite dans le marbre, loin de là.
L'aspect distribué de Git se manifeste par différents aspects. Le fait qu'il puisse être utilisé comme client ou serveur tout d'abord, mais aussi que l'on puisse « pousser » ou récupérer des données vers/depuis des tiers.
Comme nous l'avons vu dans la partie précédente de ce dossier, lorsque l'on clone un dépôt distant, il est considéré comme un remote du dépôt local. Mais Git a cela de particulier qu'il permet de ne pas se limiter à un seul et que l'on peut ajouter autant de remotes qu'on le souhaite. Ce qui peut avoir des avantages non négligeables.
Mais comme souvent avec cet outil, il y a quelques particularités à côté desquelles il ne faut pas passer.
Notre dossier sur la maîtrise de Git et de ses plateformes :
- Open source, libre et communs : contribuer ne nécessite pas de développer
- Apprenez à utiliser Git : les bases pour l'évolution d'un document
- Git remote : comment héberger vos documents et codes source sur un serveur
- Git : comment travailler avec plusieurs remotes
- Fork et pull request : la participation open source par l'exemple
- GitHub CLI 1.0 est disponible : comment l'installer et l'utiliser
Un dépôt, deux remotes
Dans cet article nous partirons du principe que vous disposez des bases concernant les concepts de Git et que vous l'avez d'installé sur votre machine. Si ce n'est pas le cas, nous vous invitons à lire notre précédent tutoriel.
Pour commencer nous allons cloner le dépôt d'un projet depuis GitHub :
git clone https://github.com/davlgd/pwa-static-winget.git
Comme nous l'avons vu dans l'article précédent, cela crée un dépôt local, y place les données et définit l'URL comme celle du remote principal, nommé origin par convention. On peut le voir avec la commande suivante :
cd pwa-static-winget
git remote -v
Vous pouvez très bien modifier son nom (git remote rename
) ou son URL (git remote --set-url
) à tout moment. Attention dans le premier cas, il faudra alors penser à indiquer le nom du remote dans vos différentes commandes. Avec origin ce n'est pas toujours nécessaire puisqu'il est considéré comme remote par défaut.
Nous allons maintenant créer un dépôt secondaire qui sera utilisé comme un remote. Pour vous éviter d'avoir à utiliser plusieurs machines, nous allons le faire en local, sur votre ordinateur. C'est peu utile, mais possible.
cd ..
git clone --bare https://github.com/davlgd/pwa-static-winget.git
Vous obtenez deux dossiers : pwa-static-winget
, un dépôt local classique cloné depuis GitHub et pwa-static-winget.git
un dépôt nu (bare) cloné depuis GitHub mais pouvant être utilisé comme remote.
C'est ce que nous allons faire, en le nommant « second » :
cd pwa-static-winget
git remote add second ../pwa-static-winget.git
git remote -v
Cette fois, vous devriez avoir deux remotes liés à votre dépôt local et obtenir le résultat suivant :

Pousser des modifications vers le second remote
On va maintenant modifier les données du dépôt local et les envoyer à notre nouveau remote :
echo > "Hello, World !" > Hello.md
git add Hello.md
git commit -a -m "Ajout d'un message"
git push second master
Dans la dernière ligne, on précise que l'on envoie la branche principale (master). Ce n'est pas nécessaire, mais autant prendre l'habitude de le faire si vous travaillez régulièrement avec différentes branches.
Gérer plusieurs remotes en une seule commande
Lorsque vous utilisez plusieurs dépôts distants, vous pourrez être amené à récupérer leurs données ou y effectuer des push
. Dans ce second cas, il peut être intéressant de le faire sur plusieurs dépôts d'un coup, par exemple si vous en maintenez un interne et un autre public, sur GitHub/GitLab, etc.
Git a néanmoins une particularité : si les commandes fetch
/pull
acceptent un argument --all
permettant de récupérer les données depuis tous les remotes enregistrés, le même argument appliqué à push
n'indique pas à Git que vous voulez pousser une branche vers tous les remotes, mais toutes les branches vers un remote particulier.
Il existe néanmoins une solution : créer un remote contenant plusieurs URL pour la commande push
. Il faut pour cela commencer par le créer de manière classique (ici a vec le nom « all »), puis lui ajouter les URL nécessaires :
git remote add all https://github.com/davlgd/pwa-static-winget.git
git remote set-url --add all ../pwa-static-winget.git
git remote -v
Vous verrez ainsi un nouveau remote disposant de deux URL pour envoyer des données, d'une seule pour les récupérer. Pour l'utiliser avec la branche principale il suffit d'utiliser la commande git push all master
.
