Je cherche à installer un serveur git pour partager des projets avec mon équipe. Je ne souhaite pas créer de compte utilisateur sur le serveur avec un accès SSH pour chaque développeur qui a besoin d'un accès git. Il semble qu'il existe deux solutions concurrentes qui couvrent ce problème: gitosis & gitolite.
Je n'ai trouvé aucune comparaison entre les deux solutions. Quelles sont les principales différences entre eux? Existe-t-il une autre solution similaire?
Réponses:
Je cherche à installer un serveur git pour partager des projets avec mon équipe.
Pour avoir un serveur git, la seule chose dont vous avez besoin sur le serveur distant est git. Si vous n'avez pas besoin d'autorisations précises (le partage avec seulement votre équipe suggère que c'est une possibilité) ou de fonctionnalités supplémentaires, vous n'avez pas besoin de gitolite ou similaire.
Si git est disponible sur le serveur distant, vous pouvez faire ce que vous demandez maintenant, sans rien faire
ssh [user@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare
Localement:
cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git push -u origin master
Si vous voulez faire des choses avec un utilisateur git dédié, la documentation pour la configuration d'un serveur git est courte - car c'est vraiment assez facile à faire.
En résumé:
.ssh/authorized_keysfichier de l'utilisateur gitgit-shellLa seule différence entre l'utilisation d'un utilisateur git dédié et non, est que si vous configurez l'utilisateur git pour l'utiliser, git-shellil ne se permettra pas de faire autre chose. En termes de serveur git, c'est identique à la solution sans installation
git push -u origin masteret vous pouvez l'utiliser git pushaprès. Je préfère gito * car à mon avis, personne qui accède à un dépôt ne devrait avoir à se soucier du chemin absolu qu'il a sur le système distant.
/home/git/l'URL pour accéder à un projet git@server:project.git.
La principale différence est que la gitose est désormais obsolète et n'est plus activement maintenue.
Gitolite est beaucoup plus complet et vient de sortir sa troisième version .
Sa caractéristique la plus intéressante est la référence virtuelle (VREF pour faire court) qui vous permet de déclarer autant de hook de mise à jour que vous le souhaitez, ce qui vous permet de restreindre un push par:
dir / nom de fichier :
disons que vous ne voulez pas que les développeurs juniors poussent les modifications vers le Makefile, car c'est assez complexe:
- VREF/NAME/Makefile = @junior-devs
nombre de nouveaux fichiers :
disons que vous ne voulez pas que les développeurs juniors poussent plus de 9 fichiers par commit, car vous voulez qu'ils fassent de petits commits:
- VREF/COUNT/9/NEWFILES = @junior-devs
détection avancée du
type de fichier : Parfois, un fichier a une extension standard (qui ne peut pas être gitignore'd), mais il est en fait généré automatiquement. Voici une façon de l'attraper:
- VREF/FILETYPE/AUTOGENERATED = @all
voir src/VREF/FILETETYPEpour voir le mécanisme de détection.
vérification de l'email de l'auteur :
certaines personnes veulent s'assurer que "vous ne pouvez pousser que vos propres commits".
- VREF/EMAIL-CHECK = @all
Voir src/VREF/EMAIL-CHECK.
vote sur commits :
Une mise en œuvre de base du vote sur Commit est étonnamment facile:
- VREF/EMAIL-CHECK = @all.
# 2 votes required to push master, but trusted devs don't have this restriction
# RW+ VREF/VOTES/2/master = @trusted-devs
# - VREF/VOTES/2/master = @devs
Voir src/VREF/VOTESpour l'implémentation.
etc...
Juste une remarque. Vous pouvez également utiliser Gerrit pour vos besoins:
Tout d'abord, il semble que Gerrit soit utilisé pour la révision du code, mais vous pouvez en fait l'utiliser également pour gérer les utilisateurs et leur donner de bonnes autorisations définies. Vous pouvez contourner la révision du code (par le biais des contrôles d'accès ) et l'utiliser uniquement pour gérer des projets et des clés ssh. Gerrit dispose d'un mécanisme de contrôle d'accès très puissant:
Vous pouvez restreindre le push pour toutes les branches, balises ou tout ce que vous pouvez imaginer qui est défini dans le document de contrôle d'accès.
Pour une solution encore plus rapide et plus sale, utilisez simplement le démon git et passez de pair à pair. Voici un article sur ce sujet.
Edit: Je reconnais que cela ne répond pas strictement à la question du PO. Je mets ceci ici principalement pour ceux, comme moi, qui rencontrent cela en cherchant un moyen bas et sale de partager du code jusqu'à ce qu'un compte github d'entreprise soit configuré.
Je déconne depuis un moment pour faire fonctionner un serveur git avec un accès LDAP, un contrôle d'accès précis, etc. J'ai trouvé une révélation: Utilisez Gitlab :
si vous voulez la méthode d'installation rapide et rapide: utilisez le programme d'installation de bitnami