Gitolite dispose d'une gestion très fine des droits qui permet de mettre des ACLs sur des objets particuliers comme les branches.

Généralement, la gestion des droits sur les SCM est centralisée et sous la responsabilité de l'administrateur du repository. Cela peut être problématique en cas d'indisponibilité de cette personne en cas de demande de modifications des droits sur un repository.

Un des points forts de gitolite est justement donc de pouvoir déléguer les droits sur un repository existant à un autre utilisateur gitolite enregistré autre que l'administrateur gitolite.

Maintenant que l'utilisateur est créé, nous allons lui créer un repository pour lequel il aura tous les droits.

Pour cela, il suffit de déclarer un nouveau repository dans le fichier gitolite.conf.

On se place donc sur la machine cliente en tant qu'administrateur gitolite et on procède à l'édition de ce fichier.

ATTENTION : Ne pas oublier de resynchroniser le repository gitolite-admin à partir du serveur de référence et de vérifier de bien être sur la branche master

On rajoute donc un repository monprojet-kitu et on donne tous les droits à l'utilisateur gituser.

Avec gitolite, tout fonctionne avec SSH et les clés. Ainsi la base de données des utilisateurs est présentée sous la forme d'une liste de clés SSH dans un répertoire versionnés dans le repositories gitolite-admin.

Nous allons donc ajouter un utilisateur gituser dans la base des utilisateurs gitolite.

Génération des clés SSH

La première étape est donc de générer l'utilisateur gituser en créant les clefs.

ptitoliv@workstations:~$ ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.

Nous pouvons à présent commencer à utiliser gitolite pour administrer les repositories du serveur de référence. Comme pour l'installation, tout va se faire à partir d'une machine cliente par l'intermédiaire d'actions "GIT" sur le repository gitolite-admin.

L'administrateur va donc faire des clones, des add, des push, des pull et des commit sur ce repository et c'est lors de la synchronisation avec le repository distant que les droits seront mis en oeuvre.

Si toute la phase d'installation s'est bien déroulée, différents composants ont été installés sur le serveur de référence et sur la machine cliente.

Sur le client

L'installation à cloné le repository gitolite-admin déployé sur le serveur de référence contenant toute la configuration (ACLs + utilisateurs)
ptitoliv@workstation:~/gitolite-admin$ ls -l
total 8
drwxr-xr-x 2 ptitoliv ptitoliv 4096 Dec 19 22:14 conf
drwxr-xr-x 2 ptitoliv ptitoliv 4096 Dec 19 22:14 keydir

La gestion des droits se fait donc par l'intermédiaire d'un repository Git. Comment se fait donc la mise en place des droits lorsqu'un administrateur ou un utilisateur disposant de droits lorsque celui-ci commit et push sur le repository gitolite ?

Sur le système contenant tous les repositories de référence est déployé tout un ensemble de hooks sous formes de hooks déployés dans chaque repository y compris le repository gitolite. Ces scripts seront exécutés a chaque fois qu'un événement git est appliqué sur le repository.

Pré requis

Pour installer gitolite, il faut disposer d'un serveur qui stockera tous les repositories GIT y compris le repository gitolite. C'est sur ce serveur que seront configurées et appliquées les ACLs sur les repositories.Ce serveur sera désigne dans la suite de cette article comme le serveur de référence.

Ce serveur doit être installé avec les composants suivants :

• git (de préférence > à la version 1.6.2)
• perl
• Serveur SSH

Gitolite est un projet open source permettant de gérer les droits sur les dépôts Git en utilisant un système d'ACL. Comme pour certains systèmes de gestion de versions tels que Subversion, il est possible de gérer les droits à différents niveaux de granularité tels que le dépôt complet ou bien certaines branches du dépôt.

Cependant, une des choses très intéressantes dans Gitolite est de pouvoir déléguer les droits d'administration à d'autres utilisateurs. L'administrateur principal de la base des dépôts pourra donc en déléguer certains à des utilisateurs enregistrés.

Git (http://git-scm.com/) est un gestionnaire de sources réparti permettant à chaque utilisateur d'avoir son propre dépôt local dans lequel il peut faire toutes les actions inhérentes à un gestionnaire de sources sans avoir a être connecté à un dépôt distant et central en permanence.

Cependant, dans une architecture utilisant Git, on a souvent un dépôt de référence sur lequel tous les développeurs viennent poser (push) et fusionner (merge) les évolutions de leur dépôt local sur ce dépôt de référence.