891 votes

Comment puis-je tirer/pousser à partir de plusieurs sites distants ?

Le résumé : existe-t-il un moyen de faire en sorte qu'un dépôt git pousse et tire à partir d'une liste de dépôts distants (plutôt que d'une seule "origine") ?

Le long : Je me trouve souvent dans une situation où je développe une application sur plusieurs ordinateurs, avec des connectivités différentes - disons un ordinateur portable en transit, un ordinateur "A" lorsque je suis dans un certain endroit, et un autre ordinateur "B" dans un autre endroit. De plus, l'ordinateur portable peut avoir une connectivité uniquement avec "A" ou "B", et parfois avec les deux.

Ce que j'aimerais, c'est que git puisse toujours "tirer" depuis et "pousser" vers tous les ordinateurs auxquels il peut actuellement se connecter, afin qu'il soit plus facile de passer d'une machine à l'autre et de continuer à travailler de manière transparente.

50 votes

Note pour les nouveaux visiteurs, à partir de 2016 : La façon actuellement correcte de procéder, sanctionnée par les classes supérieures git est inclus dans malvine 's réponse ci-dessous . La réponse acceptée est incorrecte.

0 votes

J'ai trouvé la réponse fourni ici être très bien détaillée et résumée

876voto

elliottcable Points 3946

Il n'est plus nécessaire de le faire manuellement avec des versions modernes de git ! Voir Malvoisin La solution de l'entreprise, en dessous de .

Reproduit ici :

git remote set-url origin --push --add <a remote>
git remote set-url origin --push --add <another remote>

Réponse originale :

C'est quelque chose que j'utilise depuis un certain temps sans mauvaises conséquences et qui a été suggéré par Linus Torvalds sur le site de la liste de diffusion git .

araqnid La solution de l'auteur est la bonne pour apporter le code en votre dépôt mais lorsque, comme moi, vous avez plusieurs amonts équivalents faisant autorité (je garde certains de mes projets les plus critiques clonés à la fois sur un amont privé, GitHub et Codaset), il peut être pénible de pousser les changements vers chacun d'eux, chaque jour.

Pour faire court, git remote add toutes vos télécommandes individuellement et ensuite git config -e et ajoutez un mergedremote. En supposant que vous avez ce dépôt config :

[remote "GitHub"]
    url = git@github.com:elliottcable/Paws.o.git
    fetch = +refs/heads/*:refs/remotes/GitHub/*
[branch "Master"]
    remote = GitHub
    merge = refs/heads/Master
[remote "Codaset"]
    url = git@codaset.com:elliottcable/paws-o.git
    fetch = +refs/heads/*:refs/remotes/Codaset/*
[remote "Paws"]
    url = git@github.com:Paws/Paws.o.git
    fetch = +refs/heads/*:refs/remotes/Paws/*

pour créer une télécommande fusionnée pour "Paws" y "Codaset" je peux ajouter ce qui suit après tous ces éléments :

[remote "Origin"]
    url = git@github.com:Paws/Paws.o.git
    url = git@codaset.com:elliottcable/paws-o.git

Une fois que j'ai fait ça, quand je git push Origin Master il poussera à la fois Paws/Master y Codaset/Master séquentiellement, ce qui rend la vie un peu plus facile.

114 votes

git config -e ouvre le .git/config dans votre éditeur préféré.

5 votes

Juste au cas où. Je confirme que le fait d'avoir une télécommande avec 2 urls fait toujours l'affaire en 1.7.12.4. Merci.

28 votes

J'ai nommé la télécommande "origine" "tous" pour lui donner une sémantique un peu plus propre.

593voto

araqnid Points 33350

Vous pouvez configurer plusieurs référentiels distants avec la commande git remote commandement :

git remote add alt alt-machine:/path/to/repo

Pour récupérer les données de tous les postes distants configurés et mettre à jour les branches de suivi, mais pas pour les fusionner avec les autres postes. HEAD , do :

git remote update

S'il n'est pas actuellement connecté à l'une des télécommandes, il prendra un temps d'arrêt ou lancera une erreur, et passera à la suivante. Vous devrez fusionner manuellement à partir des dépôts récupérés, ou bien cherry-pick selon la manière dont vous souhaitez organiser la collecte des modifications.

Pour récupérer la branche master depuis alt et la mettre dans votre tête actuelle, faites :

git pull alt master

Donc en fait git pull est presque un raccourci pour git pull origin HEAD (en fait, il regarde dans le fichier de configuration pour le déterminer, mais vous voyez l'idée).

Pour pousser les mises à jour, vous devez le faire manuellement pour chaque dépôt.
A push a été, je pense, conçu avec le flux de travail du dépôt central à l'esprit.

0 votes

Donc ce que vous dites, c'est que "git remote add foo ssh://foo.bar/baz" crée une forme abrégée, mais je dois toujours boucler sur eux avec un "git pull", ou boucler sur eux avec un "git merge" (quelle est la syntaxe ici, après un "git remove update" ?) Ce nom abrégé ne fonctionnera-t-il pas aussi pour "git push" ? Par exemple, ne puis-je pas "git push foo" etc (boucle) ? Merci

10 votes

"git pull" est en fait "git fetch" suivi de "git merge". "git remote update" fait juste un tas d'appels à "git fetch" pour vous. Il ne reste donc plus qu'à faire la partie "git merge". Vous pouvez dire "git merge origin/master" et il fusionnera la version origin de master dans votre HEAD actuel. "git pull origin master" fait la même chose, bien qu'il fasse d'abord une récupération (et si vous avez déjà fait git remote update, il n'y aura plus rien à récupérer, donc c'est redondant). Oui, vous pouvez dire "git push foo" et cela poussera toutes les branches correspondantes vers la branche distante appelée "foo".

2 votes

Apparemment, vous pouvez aussi avoir un seul push pour plusieurs dépôts, consultez cette réponse pour plus de détails. stackoverflow.com/questions/14290113/

312voto

Malvineous Points 2416

Depuis git 1.8 (octobre 2012), vous pouvez le faire à partir de la ligne de commande :

git remote set-url origin --push --add user1@repo1
git remote set-url origin --push --add user2@repo2
git remote -v

Entonces git push va pousser vers user1@repo1, puis pousser vers user2@repo2.

28 votes

Je déconseille fortement cette solution. Nous l'avons utilisée dans notre entreprise et avons eu de sérieux problèmes avec des crochets qui échouaient dans un dépôt, mais pas dans l'autre. Les changesets n'étaient alors présents que dans un seul dépôt.

7 votes

@MichaelSchmeißer : Je suppose que vous pouvez voir les messages d'erreur en poussant, résoudre le problème, puis pousser à nouveau pour que tout redevienne propre ?

11 votes

Le problème est que la correction du push rejeté implique de modifier les commits qui ont déjà été poussés vers l'autre repo. Donc, si quelqu'un a déjà basé son travail sur ces commits au moment où ils sont corrigés, les choses deviennent vraiment désagréables, ce qui était le cas dans notre bureau.

34voto

Nona Urbiz Points 1306

J'ai ajouté ces alias à mon ~/.bashrc :

alias pushall='for i in `git remote`; do git push $i; done;'
alias pullall='for i in `git remote`; do git pull $i; done;'

6 votes

C'est génial ! J'ai fini par avoir un alias Git : git config alias.pushall '!for i in git distant ; do git push $i; done;'

0 votes

Je pense que je préfère la solution des alias à la création d'une nouvelle télécommande. Voir aussi stackoverflow.com/questions/41372919/

1 votes

Petite modification suggérée : alias pushall='for i in `git remote`; do echo "Pushing to " $i; git push $i; done;'

29voto

felipec Points 3278

Vous pouvez ajouter des télécommandes avec :

git remote add a urla
git remote add b urlb

Ensuite, pour mettre à jour tous les dépôts, faites :

git remote update

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X