Une fois la plomberie posée, commençons par le début et la création ou la récupération d’un dépot.

Pour récupérer un dépot hébergé en local ou sur un serveur distant, rien de plus simple, c’est la commande git clone

git clone <url du dépot> [<répertoire>]

La commande va créer un répertoire portant le nom du dépot récupéré et stocker à l’intérieur l’ensemble des éléments constituant le dépot. Si vous souhaitez le stocker ailleurs, rien de plus simple, il suffit d’utiliser un deuxième argument qui sera le nom du répertoire choisi pour cloner le dépot.

Petit rappel : un dépot git n’est pas adhérent au système de fichiers. Vous pouvez donc renommer et/ou déplacer ce répertoire sans aucun impact sur son contenu.

Mais que se passe-t-il au moment du clone ?

Mais oui, que vais-je donc récupérer ? Au moment du clone vous allez à la fois récupérer les données provenant du serveur distant (qu’on appelle origin, en passant) mais aussi une partie de l’arborescence depuis votre machine en local.

Voici l’ensemble de ces éléments :

• création du dépot local pour stocker l’ensemble des data et metadata du dépot

<répertoire>/.git/

• récupération des répertoires de base en local sur votre machine dans /usr/share/git-core/templates (ici je suis sur OpenSUSE, l’emplacement peut varier selon la distribution Linux ou l’OS)

/usr/share/git-core/templates 
  ├── description 
  ├── hooks 
  │   ├── applypatch-msg.sample 
  │   ├── commit-msg.sample 
  │   ├── ... 
  │   └── update.sample 
  └── info 
      └── exclude

Vous me voyez venir avec mes gros sabots ? On se rend compte qu’une partie du dépot local ne vient pas directement du serveur mais de sa propre machine. Son contenu dépendra du mode packaging de git et ce qui a été ajouté dans ces répertoires. On trouvera essentiellement les hooks, ces scripts hyper utiles qui vous permettent d’automatiser des vérifications, renforcer un workflow d’utilisation, faire appliquer les bonnes pratiques…

• récupération des data et metadata depuis le serveur qui, en passan, dispose exactement de la même arborescence. On récupèrera ainsi tous les objets qui constituent l’historique du dépot, les branches définies, les tags…
• remplissage de la zone de travail avec l’ensemble des fichiers et répertoires reflettant l’état du projet sur la branche master

Et voilà ! Votre dépot est cloné, il n’y a plus qu’à bosser !

Oui mais alors tes templates, ils servent à quoi ?

C’est vrai quoi pourquoi ce titre ? On a vu que lors du clone, vous allez récupérer une partie du dépot local à partir de votre machine, et notamment les hooks. Eh oui, ceux-ci ne viennent pas du serveur. Vous pouvez être amené à bosser sur plusieurs projets, des langages de développement différents, des pratiques différentes. Et donc l’idée serait de pouvoir adapter ces hooks au type de projet. En voilà une idée qu’elle est bonne !

Admettons que je propose mes compétences sur du Python et du PHP, je vais donc me créer 2 types de templates avec les hooks qui vont bien pour chacun des deux. J’obtiens un truc du style :

/etc/git-templates
  ├── python 
  │   ├── description 
  │   ├── hooks 
  │   │     ├── applypatch-msg.sample 
  │   │     ├── commit-msg.sample 
  │   │     ├── ... 
  │   │     └── update.sample 
  │   └── info    
  │         └── exclude  
  └── php  
      ├── description 
      ├── hooks 
      │     ├── applypatch-msg.sample 
      │     ├── commit-msg.sample 
      │     ├── ... 
      │     └── update.sample 
      └── info    
            └── exclude

On va donc pouvoir adapter l’utilisation d’un dépot en fonction de ses spécificités. Sympa ! Et c’est la commande git clone qui va vous y aider !

git clone  --template=<template_directory> <url du dépot> [<répertoire>]

Je veux cloner le dépot de mon projet préféré écrit en Python, je vais donc entrer la commande suivante :

git clone  --template=/etc/git-templates/python <url du dépot> [<répertoire>]

Et côté serveur ?

Ca tombe bien, la structure et les commandes étant les mêmes, on peut là encore utiliser des templates de dépot ! Car de ce côté-là les hooks sont également intéressants ! Voilà comment on procèderait :

git init  --template=/etc/git-templates/python [directory]

Et hop je déploie mes hooks serveur à la volée en fonction du type de projet !

Oui mais j’utilise gitlab pour gérer mon serveur git ! Qu’à cela ne tienne ! Lors de la création d’un nouveau projet, il suffit d’utiliser l’onglet “Create from template” et choisir dans la liste proposée (qu’on pourra bien sûr personnaliser) :

Voilà c’est tout pour aujourd’hui ! Et si vous voulez en savoir plus n’hésitez pas à nous solliciter pour une formation git et/ou Gitlab !