gitosis vs gitolite ?

Question

Je suis à la recherche pour installation d’un serveur git pour partager des projets avec mon équipe. Je ne veux pas créer un compte utilisateur sur le serveur avec accès SSH pour chaque développeur qui a besoin d’un accès de git. Il semble qu’il y a deux solutions concurrentes qui couvrent cette question : gitosis & gitolite.

Je ne pouvais pas trouver toute comparaison entre les deux solutions. Quelles sont les principales différences entre eux ? Y a-t-il d’autre solution similaire ?

Answer 1

Je suis à la recherche pour l'installation d'un serveur git de partager des projets avec mon équipe.

Vous pouvez simplement utiliser git.

Avoir un serveur git la seule chose dont vous avez besoin sur le serveur distant est un serveur git. Si vous n'avez pas besoin autorisations affinées (partage seulement avec votre équipe suggère que c'est une possibilité) ou toutes les fonctionnalités supplémentaires, vous n'avez pas besoin de gitolite, ou similaire.

La non-installation de la solution

Si git est disponible sur le serveur distant, vous pouvez faire ce que vous demandez dès 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 les utilisateurs de git, de la documentation pour la configuration d'un serveur git sont à court, car il est vraiment très facile à faire.

En résumé:

• Installer git
• Créer un utilisateur nommé git
• Ajouter votre et votre équipe de clés publiques pour les utilisateurs de git de l' .ssh/authorized_keys le fichier
• Changer le git shell utilisateur pour être git-shell
• Créer repos sur le serveur
• démarrer la commande git pull/poussant à l'git@yourserver.com

La seule différence entre un git de l'utilisateur et n'est pas, est que si vous configurez le git de l'utilisateur à utiliser l' git-shell il ne permettra pas à elle-même rien d'autre à faire. En termes d'agir comme un serveur git si, elle est identique à la non-installation de la solution

Answer 2

La principale différence est que gitosis est maintenant obsolète, et pas activement maintenu plus.

Gitolite est beaucoup plus complète, et vient de sortir son troisième version.

Sa forme la plus caractéristique intéressante est l' Virtuelle de Référence (VREF) qui permet de déclarer autant de mise à jour de crochet que vous le souhaitez, ce qui vous permet de restreindre une poussée par:

• dir/nom de fichier:
  Dites que vous ne voulez pas que les développeurs juniors de pousser des changements dans le Makefile, parce que c'est assez complexe:
  - VREF/NAME/Makefile = @junior-devs

• nombre de nouveaux dossiers:
  Dites que vous ne voulez pas que les développeurs juniors pousse plus que 9 fichiers par s'engager, parce que vous voulez leur faire des petits s'engage à:
  - VREF/COUNT/9/NEWFILES = @junior-devs

• avancé type de détection:
  Parfois, un fichier a une extension standard (qui ne peut pas être " gitignore avais), mais il est en fait généré automatiquement. Voici une façon de l'attraper:
  - VREF/FILETYPE/AUTOGENERATED = @all
  Voir src/VREF/FILETETYPE voir le mécanisme de détection.

• la vérification des auteur e-mail:
  Certaines personnes veulent s'assurer que "vous ne pouvez pousser votre propre s'engage".
  - VREF/EMAIL-CHECK = @all
  Voir src/VREF/EMAIL-CHECK.

• le vote s'engage sur:
  Une base de mise en œuvre de 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.

• et ainsi de suite...

Answer 3

Juste une note. Vous pouvez également utiliser Gerrit pour vos besoins:

Gerrit De La Revue De Code

D'abord, il semble que Gerrit est utilisé pour la révision du Code, mais vous pouvez réellement utiliser également pour la gestion des utilisateurs et de leur donner de bonnes autorisations définies. Vous pouvez contourner code d'examen(bac contrôles d'accès) et de l'utiliser pour la gestion de projets et ssh-clés. Gerrit a vraiment un solide mécanisme de contrôle d'accès:

Gerrit Contrôles D'Accès

Vous pouvez restreindre l'accès à pousser pour toutes les branches, tags ou tout ce que vous pouvez imaginer qui est défini dans les contrôles de l'accès au document.

Answer 4

Pour un effet encore plus rapide et de plus en plus sale de la solution, il suffit d'utiliser git daemon et aller peer-to-peer. Voici un article à propos de le faire.

Edit: je reconnais que ce n'est pas strictement répondre à l'OP de la question. J'ai mis ça ici, surtout pour ceux, comme moi, qui viennent à travers cette recherche d'un vers le bas et sale façon de partager le code jusqu'à ce qu'une entreprise github compte est mis en place.

Answer 5

J’ai ai été déconner pendant un certain temps pour obtenir un serveur git avec accès LDAP, fine grain de contrôle d’accès etc.... Trouvé une révélation : utilisation de Gitlab:

• dépôts Git
• accès à grains fins (autant que je sache gitlab utilise gitolite sous le capot)

Si vous souhaitez que la méthode d’installation rapide et Express : utilisez l' installateur de bitnami