Il s'agit ici d'un objectif double:

• centraliser ses codes sources, tout en conservant leur historique et variantes
• rester dans un contexte 100% privé et sous contrôle (par rapport à github par exemple)
• gérer sans limitation l'accès aux projets pour différents développeurs ayant des droits spécifiques

C'est utile à titre individuel pour développer depuis plusieurs postes (ex. poste fixe et pc portable), mais aussi pour permettre de sous-traiter facilement et sans devoir donner accès à davantage qu'il ne le faut.

L'outil opensource gitolite permet d'imposer ce controle d'accès sous une forme très simple, mais il ne se substitue ni à un bug tracking, ni à un système de "pull request" (soummission contrôlée de modifications par un tiers). Ce n'est donc pas un remplacement d'outils beaucoup plus complexes de gestion de projet tels que github ou gitlab. Mais c'est précisément aussi son intérêt: rester simple et efficace pour de petites équipes.

git est le système de versioning de source le plus utilisé et probablement le plus performant à l'heure actuelle. Il repose sur une approche distribuée de "patches" (modifications incrémentales) stockés sous forme arborescente.

Voyez cette page pour une introduction progressive et plus précise à l'usage de git.

On appelle un "repository" un lieu commun qui permet à un ou plusieurs développeurs de récupérer et pousser des modifications dans des projets git, mais cette notion même de "dépot" est subjective. En effet, ajouter un ou plusieurs "remote", n'est rien d'autre qu'indiquer un ou plusieurs lieu tiers où se trouvent des *copies* de l'arborescence que l'on a chez soi, qui servent de points de comparaison et d'approvisionnement pour d'autres développeurs. Et précisément, git excelle pour comparer, réconcilier et créer diverses versions d'un projet.

Sans aller hors-sujet, et dans tous les cas, il est utile d'avoir un "dépot central" qui sert de point d'échange principal pour le code source d'un projet. Cela sert aussi comme sauvegarde lorsqu'il se trouve sur un serveur indépendant du poste client.

Enfin, cela sert beaucoup lorsqu'une partie d'une mission doit être soummise à un développeur tiers.

Le protocole que nous utilisons ici pour git est SSH (sécurisé et crypté). Mais contrairement à l'habitude, nous n'allons pas donner un accès SSH "habituel" aux développeurs sur le serveur.

En cela, gitolite est une extension intelligente du protocole SSH, qui permet d'intercepter toutes les commandes SSH envoyées, afin de vérifier les droits entrants du développeurs, pour imposer des règles définies simplement, et ne laisser passer que les commandes git habituelles.

de ce fait, les projets git vont être géré indirectement par l'utilisateur associé à gitolite sur le serveur, et seulement lui. Cet utilisateur ne sera pas utilisé interactivement, et encore moins depuis l'extérieur.

Astuce: sur votre poste client, si besoin, simplifiez-vous l'accès au bon serveur, port et (futur) utilisateur, en ajoutant un alias vers le bon serveur et le bon port dans votre ~/.ssh/config.

On crée maintenant sur le serveur un utilisateur gitolite dédié et on installe le gestionnaires (notez que l'on passe ici par la version la plus récente de https://gitolite.com/gitolite et non la version apt):

ssh root@repos
apt update && apt install git
adduser --system --shell /bin/bash --group --home /home/gitolite gitolite  --gecos 'git handler'
sudo su - gitolite
git clone https://github.com/sitaramc/gitolite
mkdir -p bin .gitolite/logs
gitolite/install -to $HOME/bin
exit
exit

Depuis son poste client, on finalise l'installation, avec sa clé publique SSH (clé d'administrateur gitolite, qui sera nommée ici jeremie.pub, à changer bien sûr pour être plus explicite):

cat ~/.ssh/id_rsa.pub | ssh root@repos 'sudo -H -u gitolite bash -c "cat > /tmp/jeremie.pub; cd /home/gitolite; bin/gitolite setup -pk /tmp/jeremie.pub"'

Tout accès SSH sur gitolite@repos est volontairement intercepté par gitolite: ce n'est pas un compte interactif, il ne fera que des opérations git. Par défaut, un accès standard retourne la liste des projets du dépot, avec les droits que l'on a dessus, par exemple:

$ ssh gitolite@repos
hello jeremie, this is gitolite@git.mondomaine.com running gitolite3 v3.6.11-4-gef9ab68 on git 2.17.1

 R W	gitolite-admin
 R W	testing
Connection to files.tecrd.com closed.

Au delà de vous-mêmes, vous pourez ajouter/retirer des utilisateurs identifiés par leur clé SSH publique, et leur donner des droits projet par projet.

Cette configuration passe elle-même par git: les changements de configurations seront donc suivies et historisées! Depuis son poste client, on commence par récupérer le projet suivant:

git clone gitolite@repos:gitolite-admin
cd gitolite-admin/

Là se trouvent actuellement seulement deux fichiers:

• conf/gitolite.conf
• keydir/jeremie.pub

Le fichier gitolite.conf permet de configurer les droits associés à chacune des clés SSH publiques stockées dans le dossier keydir.

Pour ajouter un utilisateur marcel qui vous aurait donné sa clé SSH publique /tmp/marcel.pub, on l'ajoute d'abord dans le repository gitolite (sur votre poste, pas sur le serveur) :

cp /tmp/marcel.pub keydir/
git add keydir
git commit -m "ajout de marcel"
git push origin master

Mais jusque là, il n'aura pas davantage de droits sur les projet git!

Pour lui donner un droit de lecture seule et sur un projet nommé prj pour lequel vous auriez un accès complet, il faudra ajouter ou modifier le paragraphe correspondant dans le fichier conf/gitolite.conf, et le soummettre par git:

repo gitolite-admin
    RW+     =   jeremie

repo testing
    RW+     =   @all

repo prj
    RW+ = jeremie
    R   = marcel

Note: le fait de pousser cette modification de gitolite.conf va initialiser le projet du coté du serveur. Il suffira donc d'un simple git clone gitolite@repos:prj pour le récupérer localement.

La logique simple de gitolite implique que pour ajouter un utilisateur, ou configurer ses droits il suffit d'avoir soi-même le droit d'écriture sur sur le projet gitolite: pour marcel, ce serait fait avec la modification de ce paragraphe:

repo gitolite-admin
    RW+     =   gitolite
    RW+     =   marcel

Des droits complexes sont possibles avec gitolite, comme la gestion groupée ou l'interdiction pour une personne de faire un push sur la branche master (voyez cette section par exemple).

Pour créer un nouveau projet, il faut d'abord le déclarer dans gitolite-admin/conf/gitolite.conf, avec les droits associés:

repo <REPONAME>
    RW+ = jeremie

S'il existe déjà, ou bien si l'on a créé le projet côté client, par exemple:

mkdir REPONAME
cd REPONAME
git init
git add .
git commit -m 'initial commit' -a

Alors il faut le rattacher au serveur gitolite:

git remote add origin gitolite@repos:REPONAME
git push origin master

Si le remote existe déjà, pensez à git remote rename origin gitolite@repos:REPONAME (voir la documentation/aide git).

(source)

Il est possible et utile d'intégrer directement des dépots existants sous gitolite, en les copiant directement sur le serveur dans le dossier /home/gitolite/repositories.

Il faut vérifier que chacun des nom de projets finit bien avec l'extension .git .

Puis vérifier les droits de ces fichiers: sudo chown -R gitolite:gitolite /home/gitolite/repositories

Ensuite on les notifie à gitolite:

sudo su - gitolite
gitolite compile
gitolite setup --hooks-only
gitolite trigger POST_COMPILE

Et finalement, il faudra ajouter un paragraphe associé à chaque projet dans conf/gitolite.conf, avec les droits attendus.

Si vous rencontrez des problèmes pour faire reconnaitre un utilisateur, il y a une caractéristique à savoir, parfois vicieuse, dans la gestion des clés SSH par gitolite: si la clé de l'utilisateur est sous la forme "joe@fqdn" et que "fqdn" est bien un FQDN valide (nom de domaine internet complet et valable), alors il faut spécifier le nom "joe@fqdn" dans le fichier gitolite.conf. C'est-à-dire que "joe@here.or.there" sera valide là où "joe@here" ne l'est pas!

Dans le cas d'un email mal formé, on peut cependant spécifier l'utilisateur par son nom seulement ("joe" ici, mais ce n'est pas idéal). Explications ici ("l'idée du @suffix est de permettre à l'administrateur d'ajouter facilement plusieurs clés pour un même utilisateur").

A propos de SSH, voyez les bénéfices de configurer votre $HOME/.ssh/config sur la page ssh.

C'est (pour le moment) hors sujet par rapport à ce guide.

Mentionnons seulement quelques éléments utiles à mettre dans son ~/.gitconfig:

[merge]
  tool = meld
  ff = no
  commit = no

[color]
  ui = true

[color "status"]
  changed = red bold
  untracked = red bold
  added = green bold

[alias]
  loga = log --all --decorate --oneline --graph
  d = difftool -y

Dans son "prompt" unix, on peut aussi ajouter la branche sur laquelle on travaille, c'est pratique pour éviter les erreurs de manupipulation. Pour cela on peut modifier ou ajouter cette ligne dans son ~/.bashrc:

PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[00;32m\] \w\[\033[01;30m\]$(__git_ps1)\[\033[00m\]\n\$ '