Gitolite est le remplaçant officiel de gitosis dans les dépôts debian, il s'agit d' une refactorisation de gitosis réalisée par Sitaram Chamarty.

L'intérêt de ce nouvel interface réside d'une part dans le fait qu'un utilisateur de git ne peut pas se connecter au shell de l'utilisateur gérant les dépôts (git ou gitolite) et d'autre part, on peut gérer des permissions spécifiques aux branches.

1.Quelques bases

Pour comprendre le fonctionnement de gitolite, il faut bien appréhender le fait que l'on va utiliser un utilisateur systeme git pour faire fonctionner gitolite et gérer les dépôts.

C'est dans le répértoire de cet utilisateur que l'on installera le logiciel gitolite, c'est aussi à travers lui que s'effectuera l'authentification par clés ssh, enfin c'est lui qui gérera les permissions accordées sur les dépôts.

L'administrateur du serveur ou un utilisateur dédié à l'administration de gitolite sera utilisé pour la gestion de l'administration de gitolite, c'est sur son répertoire home que sera cloné le dépôt correspondant à gitolite-admin. C'est par son intermédiaire que nous créerons les dépôts, et les permissions via les clés publiques des utilisateurs de git. La mise à jour de la configuration s'effectuera en commitant les changements effectués sur le fichier de configuration de gitolite présent dans gitolite-admin/conf.

2.Installation de gitolite

1Si ce n'est pas déjà fait, on installe git (pour le moins) et openssh !

 > sudo apt-get install git-core openssh-server openssh-client 

2On ajoute au système l'utilisateur git

 > sudo useradd git -m -g git -d /home/git -s /bin/bash 

3 On ajoute un mot de passe au nouvel utilisateur git

 > sudo passwd git 

4A partir du compte de l'administrateur serveur standart sur lequel nous nous trouvons normalement,

on crée la clef ssh que nous appelerons admin

 ssh-keygen -t dsa 

on doit alors avoir une paire de clef dans le répertoire .ssh du compte administrateur admin et admin.pub, la clef ayant l'extension .pub étant la clef publique.

5Cette clé on va la copier via la commande ssh-copy vers le repertoire de l'utilisateur git qui à partir de là saura que les requêtes provenant du propriétaire de

cette clé seront autorisées. les clés autorisées seront copiées dans un fichier appelé .authorized-keys

 ssh-copy-id -i ~/.ssh/admin.pub <$git-user>@<$serveur> (serveur est normalement localhost,git-user est git) 

6 Maintenant nous devons changer d'utilisateur pour l'utilisateur git afin d'installer gitolite.

 > su git > git clone git://github.com/sitaramc/gitolite.git 

7On crée un répertoire bin dans lequel viendrons les executables de gitolite.

 > mkdir bin > gitolite/install -ln 

8 On se place dans le répertoire bin pour lier la clé admin.pub à gitolite.

 > cd bin > ./gitolite setup -pk ../.ssh/admin.pub 

9Lorsque c'est terminé on revient en tant qu'utilisateur "administrateur" et on clone le dépôt gitolite-admin.

 > su admin > git clone git@serveur:gitolite-admin 

10Si tout a fonctionné correctement, il doit se trouver dans votre répertoire utilisateur un répertoire nommé gitolite-admin.

Le fichier de configuration se trouve dans le sous répertoire conf et s'appelle gitolite.conf, les clés publiques des utilisateurs sont à placer dans le sous-répertoire keydir.

Pour la configuration des dépôts, je vous renvoie à la doc officielle qui est très bien faite.doc de gitolite

3.Troubleshooting !!!

Si lors de la connexion ssh le serveur demande un mot de passe alors c'est que comme pour moi, votre serveur n'a pas pu identifier la clé qu'il lui faut utiliser pour se connecter à git. Pas de panique, pour que votre serveur ssh retrouve ses petits, on créé dans le répertoire .ssh de votre dossier utilisateur un fichier de configuration spécifique. Dans ce dernier, on va créer des alias que l'on va utiliser pour se connecter avec la clé à utiliser. . Ne pas oublier de définir forward agent à yes dans le fichier.

Exemple pour un hôte gitolite :

 host gitolite user git hostname localhost identityfile ~/.ssh/admin.pub port 22  ForwardAgent yes 

Pour récupérer les dépôts, on utilisera alors l'alias créé qui se chargera pour nous de récupérer le bon fichier de clé publique.

 > git clone gitolite:gitolite-admin 

Gitolite est maintenant installé sur votre serveur. Attention à l'ordre des opérations... Et bon code à tous.

1. Objectifs de git

         Git permet de versionner le travail effectué dans le cadre de modifications, création et suppressions de fichiers. Contrairement aux autres systèmes de versionning comme subversion ou CVS, il ne se sert pas d'un serveur centralisé, les collaborateurs peuvent donc directement mettre à jour leurs dépôts, de l'un à l'autre avec ou sans serveur central.

2. Fonctionnement

Git fonctionne sur une base de données locale présente sous la forme d'un répertoire .git à l'intérieur du répertoire du travail à versionner. Lors de mis à jour du dépôt, il sera donc nécessaire de mettre à jour cette base de données locale avant toute migration du dépôt vers le serveur git.

3. Opérations de bases réalisées sur la copie locale

3.a Commande add

La commande add permet comme son nom l'indique d'ajouter un ou des fichiers au dépôle;t local.
Elle peut être utilisée comme suit :

 > add <$fichier1>,<$fichier2>,etc...  > add . ajoute tous les fichiers modifiés du répertoire pour enregistrement (commit) > add * ajoute tous les fichiers avec accés récursifs, sous répertoires inclus pour l'enregistrement 

3.b Commande commit

La commande commit enregistre les changements indiqué par la commande add
Sa syntaxe est la suivante :

 > commit (tout seul, il ouvre l'éditeur de texte nano pour documenter le commit). > commit -m '<$contenu du message>' version raccourcie sans utilisation de l'éditeur. > commit -a ou $commit -am '<$contenu du message="">' fait un contrôle préalable des mises à jour à enregistrer, remplace la commande add <$fichier> 

4. Création d'un nouveau dépôt qui contiendra les données locales du dossier de travail à versionner

Il y a deux possibilité lorsque l'on travaille avec git :

1. Le répertoire de travail n'a pas encore de dépôt

Dans ce cas on execute la commande git init, qui initialise le dépôt en créant le sous répertoire caché .git dans le répertoire de travail.

 > git init 

2. Un dépôt distant existe déjà :

On se place alors dans le répertoire parent du répertoire de travail et on clone le dépôt distant avec la commande git clone.

> git clone <$git-user>@<$git-server>:<$repo-name>

5. configuration du dépôt local 

On configure alors le dépôt local en renseignant le nom d'utilisateur du dépôt et son adresse emal par les commandes.

 git config --global user.name <$user-name> git config --global user.email <$user-email> 

6.  commandes liées à la mise à jour du dépôt local 

1.git add

git add permet de suivre les modifications des fichiers du répertoire de travail par rapport à ceux du dépôt courant et les marquer avant enregistrement.

 git add   <$fichier1>,<$fichier2> git add . (Récupére les fichiers et répertoires situés à la racine du dépôt sans exploration des répertoires et sous répertoires) git add * (Récupére l'ensemble des fichiers, avec accès récursif aux répertoires et sous répertoires) 

2.git status

La commande status permet de comparer les fichiers du répertoire de travail et ceux du dépôt courant (dernier commit)

 git status -s liste des fichiers modifiés avec type de modification format abrégé pour le format complet utiliser git status seul 

3.git diff

Git diff permet de visualiser les changements opérés dans les fichiers.

 > git diff --cached cette option permet de visualiser les contenus actifs pour mise à jour du dépôt, c'est à dire ceux qui seront modifiés lors du prochain commit > git diff –HEAD cette option liste les lignes modifiées ou non depuis le dernier commit 

4.git commit

Git commit permet l'enregistrement des modifications dans le dépôt local. Attention, si l'on utilise la commande git commit seule, un message des modifs effectuées est demandée au moyen de l'éditeur de texte.

 > git commit -a Cette option permet de suivre automatiquement les fichiers avant le commit. > git commit -m '<$message' permet d'éviter l'apparition de l'éditeur de texte pour la rédaction du message de commit > git commit -am '<$contenu>' permet d'effectuer les deux opérations ci dessus 

5.git reset

 git reset HEAD --file <$fichier> permet d'inverser le marquage d'un fichier équivalent de git unstage <$fichier> 

 git reset –mode  <$commit> permet de revenir à un ancien commit. Le mode permet de choisir si on veut modifier le répertoire de travail, l’index ou le dépôt Les modes disponibles sont : --soft, pour modifier uniquement le dépôt --mixed, pour modifier dépôt et index --hard, pour modifier dépôt, index et répertoire de travail 

6.git revert

La commande git revert permet d'inverser un ou plusieurs commits,

 > git revert <$commit> -e '<$message>' cette commande permet de modifier le contenu du message du dernier commit > git revert <$commit> -n permet de ne pas créer un commit pour l'inversion 

7.git rm

La commande rm permet d'enlever des fichiers du suivi, (des fichiers de configuration par exemple) et les efface du répertoire de travail.

 > git rm --cached <$fichier> permet de garder les fichiers sur le répertoire de travail en enlevant leur suivi par le logiciel de versionnement 

8.gitignore

Le fichier .gitignore contient l'ensemble des fichiers et repertoires sur lesquels n'effectuer aucun suivi. Il s'agit simplement d'une suite de fichiers ou reps. Le caractère joker * remplace toutes les occurences. *.pyc correspond à tous les fichiers de pseudo-codes python.

Il est possible de mettre le .gitignore à la racine ou en mettre plusieurs dans les diffèrents répertoires du projets.

Il est également possible d'utiliser le fichier .git/info/exclude dans le dépôt local.

Exemple :

rep/config/ "ignore tout le repertoire config"

*.pyc         "ignore tous les fichiers terminant en *.pyc"

test.txt       "ignore le fichier test.txt

7.Travail collaboratif avec git

Un dépôt à distance dipose d'une adresse de dépôt de la forme <$git-user>@<$git-server>:<$repo-name>.git par exemple git@github:myproject.git

1.Les remotes

Comme nous l'avons dit en préambule, pour partager un même travail, git n'a pas besoin de serveur centralisé et on peut utiliser plusieurs serveurs pour la mise à jour de nos dépôts. Par exemple un serveur d'entreprise et un github. Voire plusieurs collaborateurs qui possèdent leur serveur particuliers.

Chaque raccourci vers un dépôt distant s'appelle un remote, on peut créer autant de remotes que de dépôts distants à mettre à jour. Le remote par défaut est nommé origin.

 > git remote la commande seule permet de lister les remotes enregistrés. Si aucun remote supplémentaire n'a été ajouté il affichera origin. > git remote -v commande verbeuse retourne les noms de remote et les urls des dépôts distants correspondants. > git remote add <$remote> <$url-depot> cette commande ajoute l'url spécifié à l'alias correspondant au nom du remote. > git remote rm <$remote> supprime le remote nommé 

2.Les branches

Une branche permet de créer un dépôt local en « parrallèle » au dépôt principal pour pouvoir par exemple effectuer des modifications et les tester avant fusion avec le dépôt principal.

Les branches sont donc des entrées dans la base de données locale. La branche principale est nommée master.

 > git branch la commande seule permet de lister les branches du dépôt. > git branch <$nouvelle-branche> permet de créer une nouvelle branche. > git branch -d <$branche> permet d'effacer une branche existante > git checkout <$branche> permet de basculer dans le contexte de la branche, lors du git commit, les modifications seront dirigées vers la branche spécifiée. > git checkout -b <$nouvelle-branche> permet de créer la branche et de basculer automatiquement dans son contexte 

8.Mises à jour à partir du dépôt distant

Maintenant que nous avons vu l'utilité des branches et des remotes nous allons voir comment les mettre à jour, fusionner les branches et récupérer les mises à jour des dépôts distants.

 > git fetch télécharge les nouvelles branches et les données d'un dépôt sans fusionner avec la version actuelle. > git merge <$branche> précédé de git checkout master pour revenir à la branche principale avant la fusion . La commande permet la fusion de la branche concernée avec la branche principale. > git pull seule, cette commande met à jour le dépôt local à partir du distant définit par défaut et tente une fusion avec la branche principale. > git push seule, cette commande met à jour le dépôt distant à partir des données enregistrées localement lors du commit. > git (fetch, pull ou push) <$remote> optionnel <$branche> optionnel Les commandes push pull et fetch peuvent avoir des effets réduits si on spécifie la branche que l'on veut mettre à jour. > git push <$remote> <$branche> -u spécifie le nom du remote et celui de la branche par dé à utiliser lors des prochains pushs. 

9.Autres commandes

 > git rebase origin précédé de git checkout $lt;$nom branche> applique la fusion d'une branche sous forme de patch et permet de garder un historique de la branche fusionnée sous la forme d'une serie de commits. > git rebase --continue permet de contourner les conflits qu'il faudra résoudre manuellement > git rebase --abort permet d'annuler une opération de rebase en cours