Comment configurer un référentiel git existant pour qu'il soit partagé par un groupe UNIX

J'ai un repo git existant (un simple) qui n'a jusqu'à présent été accessible en écriture que par moi. Je veux l'ouvrir à un groupe d'utilisateurs UNIX, foo, afin que tous les membres de foo puissent y pousser. Je suis conscient que je peux facilement configurer un nouveau repo git avec:

git init --bare --shared=group repodir
chgrp -R foo repodir

Mais j'ai besoin de l'opération équivalente pour un répertoire de repo existant .

Essayez ceci pour faire fonctionner un référentiel existant repodirpour les utilisateurs du groupe foo:

chgrp -R foo repodir                 # set the group
chmod -R g+rw repodir                # allow the group to read/write
chmod g+s `find repodir -type d`     # new files get group id of directory
git init --bare --shared=all repodir # sets some important variables in repodir/config ("core.sharedRepository=2" and "receive.denyNonFastforwards=true")

Dans le repo dir, exécutez les commandes suivantes:

git config core.sharedRepository group
chgrp -R foo repodir
chmod -R g+w repodir

Edit: Pour groupéviter une confusion fréquente, est un mot clé réel, vous n'êtes pas censé le remplacer par le nom du groupe.

En fusionnant les réponses @David Underhill et @kixorz , j'ai créé ma propre solution (définitive).

C'est pour les dépôts nus et les dépôts non nus . Il n'y a que peu de différences entre eux, mais de cette manière, c'est plus clair.

REPOSITAIRE NU

cd <repo.git>/                            # Enter inside the git repo
git config core.sharedRepository group    # Update the git's config
chgrp -R <group-name> .                   # Change files and directories' group
chmod -R g+w .                            # Change permissions
chmod g-w objects/pack/*                  # Git pack files should be immutable
find -type d -exec chmod g+s {} +         # New files get directory's group id

où:

• <repo.git>est le répertoire du référentiel nu, généralement sur le serveur (par exemple my_project.git/).
• <group-name>est le nom du groupe pour les utilisateurs git (par exemple, les utilisateurs ).

REPOSITORY NON NU

cd <project_dir>/                         # Enter inside the project directory
git config core.sharedRepository group    # Update the git's config
chgrp -R <group-name> .                   # Change files and directories' group
chmod -R g+w .                            # Change permissions
chmod g-w .git/objects/pack/*             # Git pack files should be immutable
find -type d -exec chmod g+s {} +         # New files get directory's group id

où:

• <project_dir>est le répertoire du projet contenant le .gitdossier.
• <group-name>est le nom du groupe pour les utilisateurs git (par exemple, les utilisateurs ).

Ce n'est probablement pas nécessaire, mais il convient de noter que cela git init --bare --shareddéfinit également l' option denyNonFastForwards .

git config receive.denyNonFastForwards true

La signification de cette option est la suivante:

receive.denyNonFastForwards

Si vous rebasez des commits que vous avez déjà poussés et que vous essayez de les pousser à nouveau, ou si vous essayez de pousser un commit vers une branche distante qui ne contient pas le commit vers lequel pointe actuellement la branche distante, vous serez refusé. C'est généralement une bonne politique; mais dans le cas du rebase, vous pouvez déterminer que vous savez ce que vous faites et que vous pouvez forcer la mise à jour de la branche distante avec un drapeau -f dans votre commande push.

(depuis http://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration )

En plus des réponses ci-dessus pour autoriser un groupe à lire / écrire, vous devez également ajouter l'utilisateur au groupe (dites «foo»).

sudo usermod -a -G [groupname] [username]

Remarque: vous devrez d'abord créer un utilisateur s'il n'existe pas