Name: Tremplin Numérique
Price range: $$$

Les hooks Git sont des scripts bash qui s’exécutent avant ou après les commandes Git, telles que les commits et les push. Ils vous permettent d’automatiser les actions répétitives dans votre référentiel, ainsi que d’appliquer des filtres et des vérifications à votre workflow Git.

Sommaire

Que sont les crochets Git ?

Les hooks Git ne sont en réalité que des scripts bash avec un nom spécial, dans le .git/hooks/ dossier. Git invoquera automatiquement ces fonctions lors de l’exécution de certaines tâches, vous permettant de vous « accrocher » au workflow Git pour le modifier avec votre propre code.

Les dépôts Git sont initialisés avec quelques exemples ; tout ce que vous avez à faire pour les appliquer est de décommenter l’extension. Cela signifie que vous ne pourrez avoir qu’un seul script par crochet, donc si vous voulez faire plusieurs choses, vous devrez les combiner ou déléguer à d’autres scripts.

Alors, à quoi pouvez-vous les utiliser ? Eh bien, toute tâche qu’un script bash peut accomplir fonctionnera. Deux cas d’utilisation courants sont les tests automatisés et l’application de filtres/vérifications sur les commits sortants.

Les tests sont une partie importante de tout flux de travail. Bien que les hooks Git ne remplacent absolument pas un pipeline d’intégration continue/déploiement continu (CI/CD) approprié, qui exécutera des tests avant la révision et le déploiement, les exécuter localement vous aidera à détecter les échecs avant qu’ils ne disparaissent.

De même, vérifier le contenu des commits pour éviter de pousser du code indésirable peut être très utile, bien que cela vous oblige à être suffisamment intelligent pour détecter le problème avant qu’il ne devienne un problème. Si vous utilisez souvent du code de débogage qui ne devrait jamais être validé, vous pouvez le tester et l’empêcher.

Il existe de nombreux hooks Git parmi lesquels vous pouvez choisir, que vous pouvez lire dans la documentation de Git, mais les plus utiles sont :

pré-engagement, post-engagement
pré-poussée
après le paiement
commit-msg

Chaque hook prendra des arguments dans le script, auquel vous pouvez accéder avec $1, $2, etc.

Partage de crochets Git

Les hooks Git sont uniquement destinés au référentiel local et ne sont pas transmis à la télécommande. Vous êtes libre de configurer les hooks Git que vous souhaitez sans affecter vos collègues, vous pouvez donc, par exemple, créer un environnement de test local qui dépend de la configuration de votre PC, à chaque validation, sans aucun problème.

Si vous souhaitez partager des hooks Git avec votre équipe, vous pouvez créer un nouveau dossier pour eux qui sera suivi dans Git, comme .githooks, et définissez la valeur de configuration pour core.hooksPath:

git config core.hooksPath .githooks

Comme les hooks par défaut, cette configuration est par dépôt, votre équipe devra donc également définir cette valeur de configuration.

Comment utiliser les crochets Git

Comme la plupart des techniques d’automatisation, la façon dont vous utilisez les hooks Git dépend en grande partie de vous et du flux de travail de votre référentiel, mais il existe quelques cas d’utilisation courants.

Si vous vouliez vérifier le contenu des commits, vous pouvez utiliser git diff pour afficher le diff ligne par ligne, puis le saisir pour trouver des correspondances. Dans ce cas, cela bloque toute utilisation de la fonction Debug.Log en sortant avec un code non nul :

if test $(git diff --cached | grep -E "Debug.Log(" | wc -l) != 0 then
    exit 1
fi

Ou, vous pouvez tester le message de validation réel. L’échantillon pré-push utilise un test similaire, mais enregistre la sortie de git rev-list au lieu. Cela vérifie les commits marqués comme travail en cours (WIP) et refuse de les pousser.

Un autre cas d’utilisation courant consiste à exécuter des tests automatiquement. C’est à vous de décider si vous voulez que cela soit à chaque validation ou juste avant que les modifications ne soient transmises à la télécommande.

Dans les deux cas, c’est aussi simple que d’exécuter votre commande de test, d’obtenir l’état de sortie de la dernière commande et de générer une erreur en cas d’échec. Cet exemple exécute des tests pour une application .NET :

#!/bin/sh
exec dotnet test "./UnitTests/UnitTests.csproj" --filter "Category!=Integration"

if [ $? -ne 0 ]; then
    echo "Tests must pass before commit!"
    exit 1
fi

Il existe des outils pour vous aider; Husky exécutera facilement des tests NodeJS avec un paramètre de configuration dans package.json, qui s’appliquera également à tous vos coéquipiers.

{
 "husky": {
  "hooks": {
   "pre-commit": "npm test",
   "pre-push": "npm test",
   "...": "..."
  }
 }
}

Cependant, cela ne remplace pas la mise en place de tests réels sur le référentiel faisant autorité. Il existe des scénarios où vos tests locaux peuvent réussir, mais les tests distants échoueraient, notamment dans les cas où vous ne préparez pas toutes les modifications à pousser.