Question Comment partager un référentiel Git avec plusieurs utilisateurs sur une machine?


J'ai un référentiel Git sur un serveur de transfert que plusieurs développeurs doivent pouvoir exploiter. git-init semble avoir un drapeau très proche de ce que je recherche: --shared, sauf que j'aimerais que plusieurs personnes aient accès à ce référentiel également. le git-clonede --shared Le drapeau fait quelque chose de complètement différent.

Quel est le moyen le plus simple de modifier les autorisations d'un référentiel existant?


201
2018-06-17 01:04


origine


J'utilise "Github pour Windows" et permute entre deux comptes Github: stackoverflow.com/questions/18565876/… - Alisa


Réponses:


Les autorisations sont un ravageur.

En gros, vous devez vous assurer que tous ces développeurs peuvent écrire dans tout le référentiel git.

Passez à la solution New-Wave pour la méthode supérieure d’octroi de capacités d’écriture à un groupe de développeurs.

La solution standard

Si vous placez tous les développeurs dans un groupe spécialement créé, vous pouvez en principe simplement:

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

Puis changez le umask pour les utilisateurs à 002afin que les nouveaux fichiers soient créés avec des autorisations en écriture groupe.

Les problèmes avec ceci sont légion; si vous êtes sur une distribution qui suppose umask de 022 (comme avoir un point commun users groupe qui inclut tout le monde par défaut), cela peut poser des problèmes de sécurité ailleurs. Et tôt ou tard, quelque chose va bousiller votre système de permissions soigneusement conçu, mettant le repo hors d’action jusqu’à ce que vous obteniez root accédez et corrigez-le (c'est-à-dire, relancez les commandes ci-dessus).

La solution New-Wave

Une solution supérieure - bien que moins bien comprise et nécessitant un peu plus de prise en charge des systèmes d’exploitation / des outils - consiste à utiliser les attributs étendus POSIX. Je ne suis venu dans cette région que récemment, et mes connaissances ne sont donc pas aussi intéressantes qu’elles pourraient l’être. Mais fondamentalement, une liste de contrôle d'accès étendue permet de définir des autorisations sur plus de 3 emplacements par défaut (utilisateur / groupe / autre).

Alors encore une fois, créez votre groupe, puis lancez:

setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

Cela configure la liste de contrôle d'accès étendue pour le groupe afin que les membres du groupe puissent lire / écrire / accéder aux fichiers déjà présents (la première ligne); Ensuite, indiquez également à tous les répertoires existants que la même liste de contrôle d'accès doit être appliquée aux nouveaux fichiers (la deuxième ligne).

J'espère que cela vous amène sur votre chemin.


171
2018-06-17 06:00



git init a un paramètre appelé --shared qui définit la variable core.sharedRepository pour le travail en groupe. Vous pouvez également définir la variable sur un référentiel existant. Cela supprime la nécessité de définir manuellement umask, car git le définira comme une valeur raisonnable avant de manipuler des fichiers. - ptman
+1 pour les attributs étendus POSIX - une nouvelle pour moi! - RobM
Quand j'ai fait chmod -R g+swXCela rendait Git très mécontent et il a décidé que ce n'était plus un dépôt git ("repo ne semble pas être un dépôt git"). Je devais chmod g-s tous les des dossiers. Pour définir le bit setgid sur le des annuairesessayer find /path/to/repo -type d -print0 | xargs -0 chmod g+s. Toujours faire le chgrp -R thegroup /path/to/repo. - rescdsk
chmod -R g+swX gitrepo appliquera le bit setguid aux fichiers, ce qui constitue un risque pour la sécurité. Au lieu de cela, vous pouvez utiliser find . -type d -exec chmod g+s {} + l'appliquer uniquement aux répertoires. - Ian Dunn
ACL (setfacl) n'a pas de paramètre pour setgid pour appliquer de nouveaux fichiers et sous-répertoires créés dans un répertoire afin d'hériter de son ID de groupe. Par conséquent, vous devez définir setgid séparément via chmod. L'option --shared de Git (git-scm.com/docs/git-init), cependant, vous permet de définir et de remplacer le umask de l'utilisateur. - Chase T.


si vous avez créé le référentiel (ou cloné un nouveau référentiel nu sur un référentiel existant) avec

$ git init --shared=group 

ou

$ git init --shared=0NNN

Git est supposé gérer les autorisations au-delà de ce que votre umask par défaut fournit. Enfin, cela est vrai sur ma version de Git (1.6.3). Bien entendu, cela suppose que vos utilisateurs appartiennent au même groupe.

Si j'avais besoin de gérer des utilisateurs dans plusieurs groupes avec des degrés variables de lecture / écriture, je choisirais la gitose. J'ai aussi entendu parler de gitolite (http://github.com/sitaramc/gitolite), un fork de gitose qui permet de fournir des autorisations au niveau de la branche, ne peut cependant pas dire que je l’ai tous personnellement utilisé.


113
2018-02-17 05:40



C'est certainement la bonne réponse. - ELLIOTTCABLE
J'ai eu ce problème et c'est de loin la meilleure réponse. Le seul problème est que le --shared l'argument prend en octal, pas en hexadécimal. Je l'ai confirmé dans la source de Git 1.7.8 et le deuxième exemple devrait être git init --shared=0NNN. - qpingu
Quel est NNN- masque de permission, numéro de groupe ou autre chose? - Craig McQueen
En passant, "groupe" ci-dessus est un mot clé, pas un espace réservé pour le nom de votre groupe. Vous affectez le groupe à l'aide de la commande chgrp. Pour un nouveau repo c'est git init --bare --shared=group myproj où myproj est votre nom de repo, suivi de chgrp -R mygroup myproj où mon groupe est le nom de votre groupe. - labradort
Sachez que si vos utilisateurs effectuent des validations lorsque leur groupe par défaut est différent de ce qu'il devrait être, cela peut tout gâcher. Pour résoudre ce problème, vous aurez besoin que chaque utilisateur chgrp chaque fichier qu'il possède dans le référentiel vers le bon groupe. Cela se reproduira à moins que vous ne trouviez comment faire en sorte que tout le monde crée / modifie de nouveaux fichiers dans / vers le bon groupe avant de valider et de pousser. - ragerdl


Cela n'a pas été dit, je veux donc l'ajouter rapidement.

Pour vous assurer que les problèmes d'autorisations ne coupent pas leur tête laide, assurez-vous de définir les éléments suivants dans le fichier de configuration de votre référentiel partagé git:

[core]
    sharedRepository = true

Cela garantira que les paramètres "umask" de votre système sont respectés.


50
2018-03-09 05:52



Selon git-config (1) (kernel.org/pub/software/scm/git/docs/git-config.html) core.sharedRepository, vous devez définir ceci sur "umask" ou "false" pour que git respecte le umask de l'utilisateur. - David Schmitt
Ceci et la réponse de user35117 est correcte. Notez que "true" est identique à "groupe", et cela peut être défini avec la commande git config core.sharedRepository true. - ColinM
Est-ce que cela change toujours la propriété d'un fichier quand il est poussé à distance? - Duc Tran
Si vous souhaitez configurer cela lors du clonage plutôt qu'après, l’équivalent de git init --shared est git clone --config core.sharedRepository=true. Étrange de git à utiliser --shared pour des significations différentes dans des commandes similaires. - stevek_mcc


le Manuel utilisateur Git décrit comment partager un référentiel de plusieurs façons.

Des moyens plus compliqués, mais riches en fonctionnalités, de partager des référentiels sont les suivants:

Nous utilisons GitHub pour une équipe de 6 développeurs.


21
2018-06-17 07:35



J'aime la gitose. C'est un moyen assez efficace de contrôler l'accès en fonction des clés publiques. - Mike Mazur
Comment l'une de ces solutions résout-elle le problème de "J'aimerais que plusieurs personnes accèdent à ce référentiel"? - womble♦
jetez un oeil à la gitose. celui-là résout votre problème. - pilif
Lorsque vous partagez le référentiel, les utilisateurs pourront en tirer. Ils devront probablement le cloner ou ajouter une branche distante. La documentation que j'ai liée vous guidera très clairement dans la résolution de votre problème; J'ai utilisé toutes les méthodes décrites pour aider les développeurs à collaborer avec le code source avec Git. À ma connaissance, ServerFault n'est pas destiné à une prise en main. - jtimberman
Je suis d'accord avec l'utilisation de la gitose. Il résout le problème des autorisations en utilisant un seul compte authentifié par plusieurs clés SSH. Il est également entièrement géré via git commits. - Jeremy Bouse


Regardez aussi gitolite pour héberger votre référentiel git. La gitose n'est apparemment plus en train de se développer.


9
2018-01-19 08:55





Un moyen de corriger les autorisations dans le référentiel partagé, afin d'éviter les problèmes d'autorisations lors de l'insertion, consiste à créer un script de hook post-mise à jour qui le fera exactement. Cela devrait fonctionner dans n'importe quelle version de Git.

Supposons que vous ayez un référentiel partagé dans /myrepo.git. Tous les fichiers de ce référentiel appartiennent à dire mysharedgroup. Tous les utilisateurs poussant vers ce référentiel doivent appartenir à mysharedgroup également. Maintenant, créez le fichier suivant (en changeant mysharedgroup à vos préférences):

/myrepo.git/hooks/post-update

#!/bin/sh
chmod -R g+w . 2>/dev/null
chgrp -R mysharedgroup . 2>/dev/null

4
2017-09-27 14:35



la bonne réponse lorsque les utilisateurs ont différents groupes par défaut - Pat
Si vous définissez le bit setgid sur un répertoire, les fichiers créés par les utilisateurs hériteront de la même propriété de groupe que le répertoire (si les utilisateurs appartiennent à ce groupe). Même si ce n'est pas le groupe par défaut des utilisateurs. Alors ce crochet n'est pas nécessaire. C’est ce que la réponse de @ womble (et mon commentaire à ce sujet) fait. - rescdsk
Sur ma machine centos7, après avoir essayé toutes les solutions répertoriées sur cette page, une variante de la solution @ bkmks ci-dessus était la seule option qui fonctionnait réellement (définition des points d'ancrage post-fusion et post-paiement au lieu de post-mise à jour comme ci-dessus). - Mike Godin


Pour regrouper les éléments de bon conseil des différentes autres réponses et commentaires sur la mise en place d'un nouveau référentiel:

Si vous configurez un nouveau dépôt myrepo dans /srv/git pour le groupe mygroup, Voici ce que vous voulez:

mkdir /srv/git/myrepo.git
chgrp mygroup /srv/git/myrepo.git
git init --bare --shared /srv/git/myrepo.git
  1. la première ligne crée le repo dir
  2. la deuxième ligne définit son groupe à mygroup
  3. la troisième ligne initialise un rapport nu avec la configuration suivante:
    1. core.bare = true: en faire un repo nu
    2. core.sharedrepository = 1 (pareil que core.sharedrepository = group): le répertoire repo et tous les répertoires créés ultérieurement y seront gérés par git pour permettre mygroup autorisations de lecture, d’écriture et d’exécution (avec le bit sgid également défini - afin de fonctionner avec les utilisateurs pour lesquels mygroup n'est pas leur groupe principal)
    3. receive.denyNonFastforwards = 1: refuser les poussées non rapides vers le repo

Si vous souhaitez affiner les autorisations des utilisateurs, des groupes ou des autres utilisateurs, utilisez --shared=0NNN, où NNN sont les bits d'utilisateur, de groupe et autres types pour des dossiers (les bits execute et sgid sur des annuaires sera gérée de manière appropriée par git). Par exemple, cela permet un accès en lecture et en écriture à l'utilisateur, ainsi qu'un accès en lecture seule au groupe (et aucun accès aux autres):

git init --bare --shared=0640 /srv/git/myrepo.git

Cela permet un accès en lecture et en écriture à l'utilisateur et au groupe (et aucun accès aux autres):

git init --bare --shared=0660 /srv/git/myrepo.git

Cela permet un accès en lecture et en écriture à l'utilisateur et au groupe, ainsi qu'un accès en lecture seule à d'autres:

git init --bare --shared=0664 /srv/git/myrepo.git

Notez que si vous n'autorisez pas l'accès en écriture au groupe, assurez-vous de commencer par l'utiliser. chown définir le propriétaire du référentiel, puis exécuter le git init commande en tant qu'utilisateur (pour vous assurer que le référentiel est initialisé avec le propriétaire correct pour tous les fichiers et sous-répertoires initiaux).


3
2018-05-26 01:24



Plus correct que les réponses de vote plus élevées. - XO01


Vous pouvez utiliser git-daemon pour partager le référentiel. Lisez la documentation pour git-daemonpour plus d'informations.

MODIFIER:

Voir aussi cet article 8 façons de partager votre dépôt git.


2
2018-06-17 02:58