web-dev-qa-db-fra.com

gitose vs gitolite?

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 ayant besoin d'un accès git. Il semble que deux solutions concurrentes couvrent ce problème: la gitose et la gitolite.

Je n'ai pu trouver aucune comparaison entre les deux solutions. Quelles sont les principales différences entre eux? Existe-t-il une autre solution similaire?

gitgitosisgitolite
138
greydet

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 votre équipe ne le suggère pas, 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

Configurer un serveur git est facile.

Si vous voulez faire quelque chose avec un utilisateur git dédié, les docs pour configurer un serveur git sont courts - parce que c'est vraiment très facile à faire.

En résumé:

  • Installer git
  • Créer un utilisateur nommé git
  • Ajoutez vos clés publiques et celles de votre équipe au fichier .ssh/authorized_keys De l'utilisateur git
  • Changez le shell de l'utilisateur git en git-Shell
  • Créer des dépôts sur le serveur
  • démarrez git pull/pushing à [email protected]

La différence seulement entre utiliser un utilisateur git dédié et non, est que si vous configurez l'utilisateur git pour qu'il utilise git-Shell, Il ne le fera pas. se permettre de faire autre chose. Pour ce qui est d’agir en tant que serveur git, c’est identique à la solution de non-installation.

190
AD7six

La principale différence est que la gitose est maintenant obsolète et n'est plus maintenue activement.

Gitolite est beaucoup plus de fonctionnalités complètes , et vient de publier son troisième version .

Sa caractéristique la plus intéressante est le référence virtuelle (VREF) qui permet de déclarer autant de pdate hook que vous voulez, ce qui vous permet de restreindre un Push par:

  • dir/nom du fichier :
    Disons que vous ne voulez pas que les développeurs juniors appliquent des modifications au Makefile, parce que 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 petit 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), mais elle est en fait générée automatiquement. Voici un moyen de l'attraper:
    - VREF/FILETYPE/AUTOGENERATED = @all
    Voir src/VREF/FILETETYPE pour voir le mécanisme de détection.

  • vérifiant l'email de l'auteur :
    Certaines personnes veulent s'assurer que "vous ne pouvez que pousser vos propres commits".
    - VREF/EMAIL-CHECK = @all
    Voir src/VREF/EMAIL-CHECK .

  • vote sur les commits :
    Une implémentation de base du vote sur un 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/VOTES pour la mise en œuvre.

  • etc...

140
VonC

Juste un sidenote. Vous pouvez également utiliser Gerrit pour vos besoins:

Révision de code Gerrit

Tout d’abord, il semble que Gerrit soit utilisé pour la révision du code, mais vous pouvez l’utiliser également pour gérer les utilisateurs et leur donner des autorisations bien définies. Vous pouvez ignorer la révision du code (au moyen des contrôles d'accès ) et l'utiliser juste 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 la diffusion à toutes les branches, balises ou autres éléments définis dans le document de contrôle d'accès.

15
Fatih Arslan

Pour une solution encore plus rapide et plus sale, utilisez simplement démon git et passez d'égal à égal. Voici un article à propos de faire cela.

Edit: Je reconnais que cela ne répond pas strictement à la question du PO. Je mets ceci ici principalement pour ceux, comme moi, qui le découvrent en cherchant un moyen simple et sale de partager du code jusqu'à ce qu'un compte github d'entreprise soit configuré.

8
Tim Keating

Cela fait un moment que je bousille pour qu'un serveur git fonctionne avec un accès LDAP, un contrôle d'accès fin, etc ... A découvert une révélation: Utilisez Gitlab :

  • les dépôts git
  • accès à grain fin (afaik gitlab utilise du gitolite sous le capot)

si vous voulez une méthode d’installation rapide: utilisez le programme d’installation bitnami

2
Chris Maes