johanBleuzen

Savoir utiliser correctement Git peut vous faire gagner du temps et surtout vous permettre d’éviter de faire des bétises. Ne vous est-il jamais arrivé de dire : «Mince j’aurai pas dû commiter ça!». Bien sûr il est toujours possible de supprimer des commits qui n’ont pas été poussés vers le remote mais grâce aux hooks, on peut éviter d’avoir à éditer ses commits et prononcer cette phrase moins souvent…

En préambule, cet article n’intéressera que les utilisateurs de Git, bien que les hooks sont généralement disponibles pour la majorité des SCM disponibles.

Qu’est-ce qu’un hook ?

Rien à voir avec Peter Pan, les hooks sont des actions que l’on peut ajouter à un logiciel à un moment précis dans le cycle de vie du logiciel afin d’en modifier son workflow, pour modifier des données par exemple.

Et c’est cet exemple là qui va nous intéresser, Git propose d’innombrables hooks qui permettent de customisez les fonctionnalités de base de Git comme le checkout, le commit ou encore le branching (et il y a bien d’autres exemples)…

Ce n’est peut être pas clair comme de l’eau de roche, mais les hooks vont nous permettre de controler ce que l’on va commiter en particulier avec le hook pre-commit, en utilisant un outil d’analyse de code ou encore en exécutant une suite de tests.

Mise en place d’un hook

Pour mettre en place un hook pre-commit, il suffit de faire un petit script qui va lancer un traitement et de le placer dans le répertoire .git/hooks/ de votre dépôt local. Sauf qu’en faisant cela, vous serez le seul à pouvoir profiter du hook, donc on va faire autrement.

Une meilleur idée consiste à avoir dans votre dépôt un répertoire scripts qui va contenir le script que l’on va utiliser, donner les droits suffisant pour être exécuté et il ne reste plus qu’à faire un lien symbolique du script vers le répertoire .git/hooks/. La création du lien symbolique pourra se faire avec la commande suivante :

$> cd mon_projet_git
$> ln -s scripts/mon_script_pre-commit.sh .git/hooks/pre-commit

Maintenant lorsque vous ferez un commit, votre script sera automatiquement exécuté. Attention néanmoins à faire un script qui retourne une valeur correcte (différente de 0) lorsqu’il y a une erreur. Eviter donc les echo dans votre script.

Voici un exemple de script que j’utilise pour mon hook de ‘pre-commit’ que j’ai publié dans un gist.

Mais comment faire si on ne veut commiter sans executer le script ? Il existe le flag -no-verify dans la commande git commit qui permet de ne pas exécuter le script lorsque l’on veut commiter «rapidement».

Quel est l’utilité du hook ‘pre-commit’ ?

J’ai trois exemples qui me viennent à l’esprit :

• Je travaille sur un projet, mais je n’ai pas de système de build automatisés. Les hooks permettent de lancer automatiquement ma suite de tests avant de commiter,
• Je ne veux plus commiter de console.log() dans mes fichiers JS, donc je veux afficher un message d’erreur lorsque je trouve un fichier avec cette instruction,
• Je veux mettre à jour mon serveur de test à chaque commit.

Je suis sur que l’on peut trouver d’autres cas d’utilisations pour ce hook, mais je n’ai pas été confronté à d’autres besoins pour l’instant.

N’oubliez pas la documentation !

Maintenant que vous avez mis en place le hook sur votre machine de dev, il faut le dire à la Terre entière, commencez par informer vos collègues grâce à de la documention. Un petit fichier README fera parfaitement l’affaire. Pourquoi faire une doc ? Tout simplement parce que le hook ne sera pas activé dans les environnements des autres développeurs et qu’ils devront faire la démarche d’installer le hook! Donc, n’hésitez pas à le documenter :

• Quel traitement fait-il ?
• Ou se trouve-t-il dans le dépôt ?
• Comment s’active-t-il ?

Conclusion

Comme je le disais dans l’article, il existe de nombreux hooks avec git et il est possible d’exécuter des traitements à la fois côté client et côté serveur. J’espère que je vous ai fait découvrir quelque chose que vous ne commiterez plus des choses par erreur…