gitosis vs gitolite? [fermé]

139

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?

Greydet
la source

Réponses:

191

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

AD7six
la source
13
Après avoir installé la bête qui est GitLab + Gitolite, si vous n'avez pas besoin d'un contrôle précis sur les projets, etc., c'est la voie à suivre.
Andrew T Finnell le
Merci pour cette réponse! En fait, quand j'ai dit que je ne voulais pas créer de compte utilisateur pour chacun, j'aurais dû également mentionner que je ne veux pas que mes utilisateurs git aient accès au shell du serveur via ssh. Avec votre solution, je pense qu'ils auraient accès au shell via l'utilisateur "git", non?
greydet le
2
@wsams: 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.
ThiefMaster
8
@ThiefMaster prend une approximation de ce que vous voulez dire, si vous mettez des dépôts dans /home/git/l'URL pour accéder à un projet git@server:project.git.
AD7six
1
@wsams a lu cette partie de la réponse "Changer le shell de l'utilisateur git en git-shell".
fabspro
142

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...

VonC
la source
3
J'utilise Gitolite depuis plus de 3 ans maintenant. Jamais eu de problèmes avec ça. Nos serveurs de production et de préparation ont un accès en lecture seule aux dépôts dont ils ont besoin. Et c'est un travail facile de partager ensuite un projet avec d'autres équipes de développement. De plus, c'est facile à installer si vous connaissez déjà unix et git :)
compliste
La documentation de Gitolite comprend des comparaisons avec des alternatives: gitolite.com/gitolite/gitolite.html#alt
Quinn Comendant
15

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.

Fatih Arslan
la source
8

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

Tim Keating
la source
2

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

Chris Maes
la source
Oui, mais GitLab (avec gitlab-shell) a perdu tous les hooks VREF que vous pouviez facilement configurer avec Gitolite. Et beaucoup de gens aimeraient qu'ils reviennent: github.com/gitlabhq/gitlab-shell/issues/14 et github.com/gitlabhq/gitlab-shell/pull/85
VonC