Forum général.général Git

Posté par  . Licence CC By‑SA.
Étiquettes :
3
26
oct.
2016

Je découvre Git et je suis maintenant en mesure d’effectuer les opérations les plus courantes, cependant il y a encore des subtilités qui m’échappent. Notamment celle-ci : la création d’un dépôt de référence (bare repository) et le premier commit depuis un « client ».

J’ai bien saisi la différence entre un dépôt "bare" et un dépôt de travail (working tree), seulement il semblerait qu’il y ait deux méthodes et je n’arrive pas à comprendre toutes les implications.

Tout d’abord, la création de l’utilisateur git et du dépôt est la même au départ :

# adduser --home /home/git --shell /usr/bin/git-shell --no-create-home --disabled-password git
# mkdir /home/git && chown -R git:git /home/git
# mkdir /home/git/.ssh && chmod 0700 /home/git/.ssh && cat /home/bob/.ssh/id_rsa.pub > /home/git/.ssh/authorized_keys
# chown -R git:git /home/git/.ssh/ && chmod 0700 /home/git/.ssh/authorized_keys
# mkdir /home/git/test.git && cd /home/git/test.git
# git init --bare --shared
# chown -R git:git . && chmod g+sw .

Et c’est à partir de là que j’ai deux voies possibles…

Solution 1)

Bob crée son propre dépôt (working tree) et « attache » celui-ci au dépôt de référence :

$ mkdir test && cd test
$ git init
$ git remote add origin git@medusa:/home/git/test.git
$ git pull origin master

Solution 2)

Directement dans le dépôt de référence :

# git remote add origin /home/git/test.git

ensuite Bob (ou les autres utilisateurs) clone directement.

Il semblerait que j’arrive au même résultat dans les deux cas (après un premier commit) :

* distante origin
  URL de rapatriement : git@medusa:/home/git/test.git
  URL push : git@medusa:/home/git/test.git
  Branche HEAD : master
  Branche distante :
    master suivi
  Branche locale configurée pour 'git pull' :
    master fusionne avec la distante master
  Référence locale configurée pour 'git push' :
    master pousse vers master (à jour)

Est-ce qu’il y a des conséquences à choisir entre l’une ou l’autre de ces deux méthodes ?

Pendant que j’y suis j’ai une autre question :

Le fichier description semble pouvoir être édité pour donner un nom au dépôt. Comment doit-on utiliser ce nom ensuite ?

  • # strictement équivalent

    Posté par  . Évalué à 1.

    Les deux méthodes sont strictement équivalentes. Cependant si tu partages un dépôt "bare" avec plusieurs personnes, une surcouche pour gérer les autorisations est la bienvenue, par exemple gitolite.

    • [^] # Re: strictement équivalent

      Posté par  . Évalué à 3.

      Merci.

      Effectivement, je découvre que git ne se préoccupe absolument pas des autorisations (ce qui est normal car ce n’est pas son boulot…). Si j’ai bien compris, pour les gérer les droits sans utiliser une surcouche comme gitolite on a deux possibilités :

      • les permissions UNIX
      • les ACL

      ça ne permet pas de gérer les autorisations par branche mais ça permet déjà de les gérer par dépôt.

      Quitte à me pencher sur les surcouches à git je lorgne du côté de gitlab qui semble offrir de nombreuses fonctionnalités, permet-il de gérer finement les autorisations ?

  • # solution 3

    Posté par  . Évalué à 2.

    git clone git@medusa:/home/git/test.git

    qui creer le dossier test dans le dossier courant
    et dans lequel tu vas pouvoir travailler

    enfin, ca c'est ce que je faisais quand j'avais besoin de faire un depot avec mes petites connaissances de git.

    • [^] # Re: solution 3

      Posté par  . Évalué à 2.

      Oui mais ça c’est quand tu veux faire un dépôt local de travail. Or tu ne peux pas le faire à partir d’un dépôt "bare" qui n’a pas déjà une branche configurée.

      C’est la manière de créer et de configurer cette branche initiale (qu’on pourra ensuite cloner) sur ce dépôt "bare", qui sert de référence, que j’avais du mal à comprendre.

      Lorsque que l’on initialise un dépôt de travail vide (non "bare") et que l’on fait un premier commit cette branche est créée et s’appelle 'master'. Lors d’un clone tout ce fait automatiquement aussi.

      Mais j’essayais de bien comprendre toutes les étapes intermédiaires. Sinon j’aurais rien compris à la suite :)

      • [^] # Re: solution 3

        Posté par  . Évalué à 2.

        en gros le bare ne fait que du stockage, on ne travaille pas dedans, il n'y a pas l'arborescence de fichier telle que tu l'as dans le dossier de travail sur ton poste.

        et il me semble que quand j'avais essayé, je ne pouvais pas faire de push sur un depot non bare.

        • [^] # Re: solution 3

          Posté par  . Évalué à 2. Dernière modification le 29 octobre 2016 à 18:08.

          le bare ne fait que du stockage, on ne travaille pas dedans

          C’est bien ça le principe si je ne m’abuse.

          il me semble que quand j'avais essayé, je ne pouvais pas faire de push sur un depot non bare.

          J’ai pas testé mais c’est ce que j’ai pu comprendre en effet : on ne peut pousser que vers un dépôt "bare".

          Cela dit, au besoin, on peut créer un dépôt de référence à partir d’un dépôt de travail avec un git clone --bare …

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.