gitosis vs gitolite? [fermé]

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?

Je cherche à installer un serveur git pour partager des projets avec mon équipe.

Vous pouvez simplement utiliser git.

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.

La solution sans installation

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

La configuration d'un serveur git est facile.

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é:

• Installer git
• Créez un utilisateur nommé git
• Ajoutez vos clés publiques et celles de votre équipe au .ssh/authorized_keysfichier de l'utilisateur git
• Changer le shell de l'utilisateur git en git-shell
• Créer des dépôts sur le serveur
• démarrer git pull / pousser à [email protected]

La 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

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:

Révision du code Gerrit

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:

Contrôles d'accès Gerrit

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 :

• référentiels git
• accès à grain fin (afaik gitlab utilise gitolite sous le capot)

si vous voulez la méthode d'installation rapide et rapide: utilisez le programme d'installation de bitnami