web-dev-qa-db-fra.com

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 utiliser. git-init semble avoir un drapeau très proche de ce que je recherche: --shared, sauf que j'aimerais que plusieurs personnes accèdent également à ce référentiel. Le git-clone 's --shared flag fait quelque chose de complètement différent.

Quelle est la façon la plus simple de modifier les autorisations d'un référentiel existant?

permissionsgitusersshare
217
Andrey Fedorov

Les autorisations sont nuisibles.

Fondamentalement, vous devez vous assurer que tous ces développeurs peuvent écrire sur tout dans le dépôt git.

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

La solution standard

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

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

Modifiez ensuite le umask pour les utilisateurs en 002, afin que les nouveaux fichiers soient créés avec des autorisations d'écriture de groupe.

Les problèmes avec cela sont légion; si vous êtes sur une distribution qui suppose un umask de 022 (comme avoir un groupe users commun qui inclut tout le monde par défaut), cela peut ouvrir des problèmes de sécurité ailleurs. Et tôt ou tard, quelque chose va bousiller votre schéma d'autorisations soigneusement conçu, mettant le repo hors service jusqu'à ce que vous obteniez l'accès root et le corrigiez (c'est-à-dire en réexécutant les commandes ci-dessus).

La solution nouvelle vague

Une solution supérieure, bien que moins bien comprise et qui nécessite un peu plus de prise en charge OS/outils, consiste à utiliser les attributs étendus POSIX. Je ne suis venu dans ce domaine que récemment, donc ma connaissance ici n'est pas aussi chaude qu'elle pourrait l'être. Mais fondamentalement, une ACL étendue est la possibilité de définir des autorisations sur plus que les 3 emplacements par défaut (utilisateur/groupe/autre).

Encore une fois, créez votre groupe, puis exécutez:

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

Ceci configure l'ACL étendue pour le groupe afin que les membres du groupe puissent lire/écrire/accéder à tous les fichiers qui sont déjà là (la première ligne); puis, indiquez également à tous les répertoires existants que les nouveaux fichiers doivent avoir cette même ACL appliquée (la deuxième ligne).

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

193
womble

si vous avez créé le référentiel (ou cloné un nouveau référentiel nu à partir d'un référentiel existant) avec

$ git init --shared=group

ou

$ git init --shared=0NNN

Git est censé gérer les autorisations au-delà de ce que fournit votre umask par défaut. C'est enfin vrai sur ma version de Git (1.6.3). Bien sûr, cela suppose que vos utilisateurs sont dans le même groupe.

Si j'avais besoin de gérer des utilisateurs dans plusieurs groupes avec différents degrés de lecture/écriture, j'irais avec la gitose. J'ai également entendu parler de gitolite ( http://github.com/sitaramc/gitolite ), une fourchette de gitose qui est suppossée pour fournir des autorisations au niveau de la branche, je ne peux pas dire que je les ai toutes utilisées personnellement cependant.

122
user35117

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

Pour vous assurer que les problèmes d'autorisations ne rognent 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.

55
Niels Joubert

Le Git User Manual décrit comment partager un référentiel de plusieurs manières.

Les moyens les plus compliqués, bien que riches en fonctionnalités, de partager des référentiels sont:

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

22
jtimberman

Regardez aussi gitolite pour héberger votre dépôt git. Apparemment, la gitose ne se développe plus.

9
mt3

Une façon de corriger les autorisations dans le référentiel partagé, afin que les utilisateurs n'aient pas de problèmes d'autorisation lors de l'envoi, est de créer un script de hook post-mise à jour qui fera exactement cela. 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 également appartenir à mysharedgroup. Créez maintenant le fichier suivant (en changeant mysharedgroup selon 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
bkmks

Pour agréger les morceaux de bons conseils des diverses autres réponses et commentaires sur la mise en place d'un nouveau référentiel:

Si vous configurez un tout 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 sur mygroup
  3. la troisième ligne initialise un dépôt 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 seront gérés par git pour autoriser mygroup les autorisations de lecture, d'écriture et d'exécution (avec le bit sgid également défini - afin de travailler avec les utilisateurs pour qui 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 d'utilisateur, de groupe ou d'autres utilisateurs, utilisez --shared=0NNN, où NNN sont l'utilisateur standard, le groupe et les autres bits pour fichiers (les bits d'exécution et sgid sur répertoires seront gérés de manière appropriée par git ). Par exemple, cela permet un accès en lecture et en écriture à l'utilisateur et 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, et 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 d'abord d'utiliser chown pour définir le propriétaire du dépôt, puis exécutez le git init commande en tant qu'utilisateur (pour vous assurer que le dépôt est initialisé avec le bon propriétaire pour tous les fichiers et sous-répertoires initiaux).

3
Justin Ludwig

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

ÉDITER:

Consultez également cet article 8 façons de partager votre référentiel git .

2
Vihang D

Faire exactement cela a fonctionné pour moi, pour un référentiel existant. Cela nécessite des conseils de plusieurs réponses et commentaires avant:

Depuis le répertoire parent de votre référentiel, sur le serveur:

chgrp -R <whatever group> gitrepo
chmod -R g+wX gitrepo
cd gitrepo
find . -type d -exec chmod g+s {} +
git config core.sharedRepository group
1
Luis de Arquer

@stevek_mcc est la réponse que je cherchais lorsque j'ai recherché cette question sur Google

git clone --config core.sharedRepository=true
0
ragerdl