Qu'est-ce qu'un hook git ?

Un hook git, c'est un script qui s'exécute à un moment donné de votre utilisation de git et qui permet de personnaliser une action.

Si ce script renvoie une erreur la commande git est alors abandonnée.

Cela permet notamment d'effectuer des vérifications et d'uniformiser l'utilisation de git au sein de son équipe.

Ce script peut être écrit en shell, bask, perl, ruby, python...

Il y a deux types de hook :

👉 les hooks clients qui sont exécutés sur les postes des développeurs avant l'envoi au repo distant

👉 les hooks serveurs, exécutés par le repo distant, après l'envoi

Les principaux hooks côté client :

💥 pre-commit : permet d'effectuer des vérifications avant commit. Ex. : Checkstyle, présence de fichiers, de documentation

💥 prepare-commit-msg : exécuté avant l'affichage de l'éditeur de commit mais après la définition du message par défaut (cas des merges, squashed, amended commits). Permet d'ajouter des informations par exemple.

💥 commit-msg : exécuter une fois le message de commit validé mais avant le commit lui-même. Permet de valider le format du message par exemple.

💥 post-rebase : exécuté après une réécriture de l'historique (git rebase). Permet par exemple de vérifier que les commits remplacés n'ont pas déjà été poussés.

💥 pre-push : exécuté avant l'envoi au remote. Permet de valider les mises à jour des refs distantes à effectuer.

Les principaux hooks côté serveur :

💥 pre-receive : permet d'effectuer des vérifications sur la liste des références qui vont être mis à jour. Permet de vérifier par exemple que les modifications sont toutes "fast-forward", que certains fichiers n'ont pas été modifiés ou pour effectuer des contrôles d'accès.

💥 update : similaire à pre-receive mais appliqué une fois par référence poussée. Le script pre-receive est appliqué une seule fois pour toutes les références mises à jour.

💥 post-receive : exécuté une fois les références mises à jour. Permet par exemple d'envoyer des notifications (envoi d'email, notification à la CI/CD, au système de bug tracking)

Comment on fait concrètement ?

Facile !

Dans votre répertoire .𝑔𝑖𝑡/ℎ𝑜𝑜𝑘𝑠 vous avez déjà des exemples de scripts, suffixés avec ".sample".

Il suffit d'enlever le suffix pour que le hook soit actif.

Bon après il faut quand même modifier le script pour faire ce que vous voulez 😅

Et pour les hooks côté serveur ? Moins facile ! Enfin, ça dépend...

Si vous hébergez votre repo git distant sur un gitlab on-premise par exemple, c'est la même chose qu'avec un hook côté client (sauf que vous le faites du côté serveur).

Par contre, si votre repo est hébergé par github, gitlab ou autres, là c'est plus compliqué car pour des aspects de sécurité, vous n'avez pas accès au répertoire .git distant.

Dans ce cas, il faut utiliser les solutions proposées par l'hébergeur (WebHooks for GitLab, ghe-hook-env-create for GitHub)

Comment je fais pour partager mes hooks côté client ?

Si le but de la mise en place d'un hook est d'uniformiser les pratiques au sein d'une équipe, il faut pouvoir partager les hooks !

Or, de base, il faut placer les hooks dans le répertoire .git/hooks et ce répertoire n'est pas versionné.

Heureusement, git a tout prévu ! Il est fort ce git !

Vous pouvez par configuration définir un autre répertoire dans lequel git ira chercher les hooks. Par exemple, vous pouvez mettre vos scripts de hook dans un répertoire .githooks qui lui sera versionné et définir la configuration suivante :

$ git config core.hooksPath .githooks

Et t'as un exemple ?

Of course, I have...

L'exemple suivant permet de vérifier que tout vos messages de commit commencent par [FT-XXX] où X désigne un chiffre (FT pour Fait Technique).

Il suffit de prendre le script suivant et de le copier dans le fichier .git/hooks/commit-msg

 #!/bin/sh

COMMIT_MSG=$1
test=$(egrep '^\[FT-[0-9]{3}\].*' "$COMMIT_MSG")
if [ -z "$test" ]
then
   echo "Bad commit message: it should begin with [FT-XXX]"
   exit 1
fi
exit 0

Et si, exceptionnellement, je ne veux pas exécuter un hook ?

Là encore, git a tout prévu !

Il suffit d'utiliser l'option --no-verify sur la commande git concernée (commit, push, rebase...).

What next ?

Avec cet article, j'ai balayé les principes de base des hooks git.

Il reste maintenant plus qu'à mettre les mains dans le cambouis et mettre en place vos propres règles.

Il existe également des outils qui permettent de facilité la mise en place des hooks comme par exemple husky ou pre-commit, en proposant notamment les scripts les plus communs que vous pouvez récupérer. Allez y jeter un oeil !

----

T'as aimé cette article ? Tu veux devenir un expert git ?

N'hésite pas à me contacter !

Contacter Fabrice !