Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Git : comment travailler avec plusieurs remotes

Parce que c'est meilleur à plusieurs
Git : comment travailler avec plusieurs remotes
Crédits : mucella/iStock

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 :

Un dépôt, deux remotes

13 commentaires
Avatar de tomdom Abonné
Avatar de tomdomtomdom- 08/10/20 à 07:00:37

Questions :

  • On peut ajouter un dépot distant supplémentaire directement sur origin (si on sait que l'on veut toujours envoyer sur l'ensemble des dépots) ?
  • Que se passe-t-il si un des dépots n'est pas disponible au moment du push ? Est-ce que lorsque le dépot redevient disponible, git status montrera que la copie locale est en avance par rapport à ce dépot distant ?

Super série d'articles :yes:

Édité par tomdom le 08/10/2020 à 07:01
Avatar de AmineSab Abonné
Avatar de AmineSabAmineSab- 08/10/20 à 07:05:36

Mais vous régalez en fait. Merci pour cette série sur Git.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 08/10/20 à 07:12:36
tomdom

Je n'ai pas testé mais tu peux sans doute ajouter une URL à origin oui, c'est un remote comme un autre, c'est juste que quand aucun n'est mentionné, c'est lui qui est utilisé.

En cas d'indispo de mémoire tu as une simple erreur, si l'un ne répond pas rien n'est envoyé. Après je ne sais plus comment ça se passe en cas d'erreur pendant le push qui serait de faire partiel (mais bon tu peux résoudre le souci en second temps pour repartir propre au pire.

Et merci pour les retours sur la série :chinois:

Avatar de Baldurien Abonné
Avatar de BaldurienBaldurien- 08/10/20 à 08:07:45

tomdom a écrit :

Questions :

  • On peut ajouter un dépot distant supplémentaire directement sur origin (si on sait que l'on veut toujours envoyer sur l'ensemble des dépots) ?

En gros, ton repo local pointe sur origin, et origin pointe sur un autre repo ?

Si oui, ça s'appelle du mirroring.

Toute la question est de savoir comment se passe la synchronisation.

Si tu as un repo bare + mirror (git clone --mirror), alors les branches du repo sont écrasées par les modifications de son remote, dés lors que tu fetch le remote manuellement (eg: git --git-dir "lerepobare.git" fetch)

Les outils comme BitBucket/GitLab/GitHub/etc, proposent plus de choix.

  • Que se passe-t-il si un des dépots n'est pas disponible au moment du push ? Est-ce que lorsque le dépot redevient disponible, git status montrera que la copie locale est en avance par rapport à ce dépot distant ?

Super série d'articles :yes:

Rien : ça échoue et ta référence origin/develop restera à l'état où elle était.

Par ailleurs, comme alternative aux remote bare, il y a aussi les bundle (git bundle) qui permet de travailler avec des repo hors lignes :)

Édité par Baldurien le 08/10/2020 à 08:07
Avatar de David_L Équipe
Avatar de David_LDavid_L- 08/10/20 à 08:56:13
Baldurien

Git bundle de mémoire c'est surtout pour générer une archive qui sera ensuite poussée sur un autre dépôt (quand il n'y a pas de lien possible directement entre les deux) non ?

Avatar de Baldurien Abonné
Avatar de BaldurienBaldurien- 08/10/20 à 09:48:12

David_L a écrit :

Git bundle de mémoire c'est surtout pour générer une archive qui sera ensuite poussée sur un autre dépôt (quand il n'y a pas de lien possible directement entre les deux) non ?

C'est vendu comme permettant de créer une archive en cas de non accès au réseau: https://git-scm.com/docs/git-bundle

Some workflows require that one or more branches of development on one machine be replicated on another machine, but the two machines cannot be directly connected, and therefore the interactive Git protocols (git, ssh, http) cannot be used.

Le problème des repo bare (dans la news), c'est pourquoi tu veux t'en servir : sur une clef USB, modulo la rapidité, ça peut passer, mais sur un disque en ligne (grogle drive, onedrive, etc), j'ai plutôt eu des écueils car la synchronisation peut parfois casser l'intégrité du repo : git va de temps à autre effectuer un garbage collector, qui aura pour effet de créer un fichier pack des objets dans GIT_DIR/objects. Or, ça, ça modifie/supprime pas mal de fichier et c'est là que le drive risque d'échouer.

Un bundle en revanche, c'est comme un zip du repo, mais en limitant le scope à ce que tu veux (même si --all quoi :D) et si la doc fait un clone, tu peux en fait rajouter un bundle comme remote et profiter de ses références :)

(et pour conclure, je ne parlerais pas git fast-export :D)

Avatar de revker Abonné
Avatar de revkerrevker- 08/10/20 à 12:58:03

Je peux voir l'état de ma branche locale directement dans la ligne de commande grâce à __git_ps1.

Dans le .bashrc, il suffit d'ajouter.

export GIT_PS1_SHOWDIRTYSTATE=1
export GIT_PS1_SHOWSTASHSTATE=1
export GIT_PS1_SHOWUPSTREAM=auto

Et ensuite, par exemple,

PS1='${debian_chroot:+($debian_chroot)}[\033[00;34m]\u@\h:[\033[00m][[\033[01;34m]\w[\033[00m]][\033[0;32m]$(__git_ps1)[\033[00m] $ ';;

C'est la mise en forme de la ligne affichée quand tu te connectes à un terminal.

Apparaîtra alors à côté du nom de la branche son statut par rapport à l'origine :

branche>, je suis en avance
branche<, je suis en retard
branche=, nous sommes égaux.

Édité par revker le 08/10/2020 à 12:59
Avatar de David_L Équipe
Avatar de David_LDavid_L- 08/10/20 à 13:06:10
revker

Oui on en reparlera sous peu, mais outre la retouche à la main du PS1 tu as aussi les thèmes Zsh qui ouvrent pas mal de possibilités sans trop se casser la tête là dessus par exemple.

Avatar de revker Abonné
Avatar de revkerrevker- 08/10/20 à 13:09:46
David_L

Ah pardon, je ne veux pas spoiler le prochain article :D

Avatar de iswt Abonné
Avatar de iswtiswt- 09/10/20 à 11:51:56

Je ne vois pas de usecase ou cela serait nécessaire?
Vous avez des exemples ?

Il n'est plus possible de commenter cette actualité.
Page 1 / 2
  • Introduction
  • Un dépôt, deux remotes
  • Pousser des modifications vers le second remote
  • Gérer plusieurs remotes en une seule commande
S'abonner à partir de 3,75 €