Comment faciliter le flux de travail de développement de votre équipe avec les crochets Git

L'une des principales exigences de travail pour une équipe ou un projet open source est l'utilisation d'un système de contrôle de version (VCS). Git est un système de contrôle de version distribué gratuit et open source permettant de suivre les modifications du code source pendant le développement de logiciels. Il a été créé par Linus Torvalds en 2005 pour le développement du noyau Linux. Il est facile à apprendre et a une petite empreinte avec des performances ultra-rapides.

Il y a de fortes chances que vous ayez déjà utilisé Git (car c'est l'un des outils VCS les plus populaires et les mieux adoptés disponibles dans la communauté de développement), et vous avez probablement déjà des connaissances sur la mise en scène et la validation de votre code en poussant et en tirant à partir d'un référentiel distant. Cet article n'abordera pas les bases des workflows git mais se concentrera principalement sur les crochets git et sur la façon de les utiliser afin d'obtenir une meilleure collaboration au sein de votre équipe. Avec la taille croissante des équipes, il devient encore plus important de garder les contributeurs en ligne et de maintenir des règles différentes concernant le code.

Que sont les crochets Git ?

Les crochets Git sont des scripts qui sont déclenchés lorsque des actions ou des événements spécifiques sont effectués dans un référentiel git. Ces actions concernent des parties du flux de travail de contrôle de version telles que la validation et la transmission. Les hooks peuvent être très utiles en automatisant les tâches de votre workflow git. Par exemple, ils peuvent nous aider à valider la syntaxe de notre base de code en fonction de certaines règles spécifiques ou à exécuter des tests avant de valider nos modifications.

Comment les faire définir ?

Les crochets Git sont une fonctionnalité intégrée, ce qui signifie que nous pouvons y accéder et commencer à les utiliser tant qu'un référentiel git est initialisé. Voyons plus en détail ce que cela signifie en essayant de les définir.

À l'aide de votre terminal préféré, créez un nouveau référentiel git.

 mkdir my-new-repository && cd my-new-repository git init ls -la

Vous remarquerez qu'un nouveau répertoire caché vient d'être créé. Ce dossier .git est utilisé à partir de git pour stocker les informations relatives au référentiel, telles que les hachages de contrôle de version, les informations sur les validations, les adresses de référentiel distant, etc. C'est aussi le dossier où se trouvent réellement les hooks pour git .git/hooks . Vous pouvez trouver des exemples de scripts préremplis automatiquement créés lors de l'initialisation. Ce sont en fait les scripts qui seront déclenchés après des actions spécifiques.

 ls .git/hooks

Certains des échantillons que vous pouvez trouver sont :

• pre-commit.sample : invoqué juste avant de faire le commit.
• commit-msg.sample : édite le fichier de message en place.
• post-receive.sample : invoqué après la mise à jour du référentiel distant.

Sous la capuche

Maintenant que nous savons où trouver les crochets, prenons un peu de recul afin de comprendre comment fonctionnent-ils réellement.

Les crochets Git sont basés sur des événements, donc tant que nous exécutons une commande git dans le flux de développement, git vérifiera les dossiers des crochets afin de trouver s'il y a un script associé à exécuter. Certains de ces scripts s'exécuteront avant ou après ces actions de flux de développement.

Un bon exemple pour nous de passer en revue et de comprendre plus précisément le flux dans lequel les hooks sont déclenchés est le workflow de validation qui est un cas d'utilisation assez familier.

Chaque fois que nous validons des modifications dans notre base de code, certains de ces crochets associés sont déclenchés dans l'ordre suivant :

1. pre-commit : inspecte l'instantané qui est sur le point d'être validé et vérifie ce qui doit être validé.
2. prepare-commit-msg : vous permet de modifier le message par défaut avant que l'auteur du commit ne le voie.
3. commit-msg : définit le message de validation sur un modèle.
4. post-commit : exécute une action juste après la fin du commit, et envoie une notification par exemple.

Dans le référentiel ci-dessus, essayons maintenant d'ajouter des scripts personnalisés avant et après validation afin de mieux visualiser le fonctionnement réel des crochets git.

 nano .git/hooks/pre-commit

Ajoutez l'extrait suivant :

 #!/bin/sh echo Changes are about to be committed

Assurez-vous que nos scripts sont exécutables :

 chmod +x .git/hooks/pre-commit

Répétez le processus ci-dessus pour le script post-commit :

 nano .git/hooks/post-commit

 #!/bin/sh echo Changes have been committed

 chmod +x .git/hooks/post-commit

Nous pouvons maintenant ajouter un nouveau fichier nano index.html avec un petit extrait HTML uniquement à des fins de démonstration (inutile d'en informer les validateurs HTML).

 <h1>Hello world from our new repository!</h1>

Nous allons ajouter les modifications dans notre base de code via la mise en scène, puis valider ceci :

 git add . git commit

Une fois la validation effectuée avec succès, nous pouvons voir la sortie suivante des deux scripts ajoutés ci-dessus :

 Changes are about to be committed Changes have been committed

Comme prévu, git a déclenché des crochets dans le flux de validation. Les scripts pre-commit et post-commit qui ont été ajoutés sont en cours d'exécution et seront exécutés dans le bon ordre (en fonction de l'ordre mentionné précédemment).

Il s'agissait d'une démonstration simple afin de comprendre comment les scripts de workflow de validation fonctionnent et comment ils sont exécutés. Pour plus de détails sur ce workflow, vous pouvez en savoir plus dans la documentation.

Dans l'exemple ci-dessus, nous avons choisi d'écrire ces deux scripts en bash mais la vérité est que git prend en charge les crochets qui peuvent être écrits dans n'importe quel langage de script que nous voulons. Ruby, Python ou JavaScript sont d'excellentes alternatives, tant que nous définissons le bon shebang à la première ligne de notre script exécutable.

Par exemple, nous pouvons réécrire le hook de pre-commit en tant que script Node.js comme ci-dessous :

 #!/usr/bin/env node console.log("Changes are about to be commited")

Crochets locaux et distants

Les hooks sont séparés entre local et distant (ou client et serveur). Alors que les hooks locaux s'exécutent avant ou après des actions spécifiques sur le référentiel local, les hooks distants s'exécutent avant ou après les push vers le serveur. Les locales ne peuvent pas être utilisées pour appliquer des politiques car leur nature permet aux développeurs de les modifier facilement. Ils sont principalement utilisés pour respecter certaines directives spécifiques que nous souhaitons appliquer au sein d'une équipe. Au cas où nous voudrions devenir plus stricts et appliquer certaines politiques pour notre référentiel, nous résidons dans des crochets distants.

Crochets locaux

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-rebase
• post-rewrite
• post-checkout
• post-merge
• pre-push

Crochets à distance

• pre-receive
• update
• post-receive

Crochets de partage

Les crochets Git consistent à les partager au sein de l'équipe. C'est la principale raison de leur existence : promouvoir une meilleure collaboration d'équipe, automatiser les processus nuisibles et nous permettre de nous concentrer uniquement sur les parties importantes de la base de code.

Comme indiqué précédemment, .git/hooks est le dossier qui héberge nos hooks personnalisés, mais cela n'est pas vraiment utile lorsque nous devons partager ces scripts au sein de l'équipe car ce dossier n'est pas suivi par git.

Une bonne approche pour résoudre ce problème consiste à ajouter tous nos crochets personnalisés dans un dossier séparé dans notre référentiel. Par exemple, nous pouvons ajouter un dossier .githooks et y enregistrer les scripts exécutables. Ensuite, lors de l'initialisation du projet, nous pouvons soit copier explicitement, soit créer un lien symbolique entre ces scripts et le dossier d'origine pour conserver nos hooks .git/hooks .

 find .git/hooks -type l -exec rm {} \\; find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \\;

Alternativement, si vous utilisez la dernière version de git (en parlant de 2.9 et plus), nous pouvons configurer directement le chemin des crochets git vers notre dossier personnalisé :

 git config core.hooksPath .githooks

Git Hooks Made Easy (un cas d'utilisation de base de code JavaScript)

Il existe des outils qui nous aident à intégrer davantage les crochets git aux besoins de notre base de code. Spécifiquement pour les bases de code JavaScript, il existe Husky avec lequel nous pouvons facilement personnaliser les actions sur les événements git via la configuration.

Par exemple, nous pouvons facilement linter notre code ou exécuter des tests dans l'événement pre-commit et procéder à la validation en fonction du succès ou non du linting, du test ou des deux.

Cela peut être accompli en étendant la configuration package.json simplement comme suit :

 { "scripts": { "test": "echo Running tests" }, "devDependencies": { "eslint": "5.16.0", }, "husky": { "hooks": { "pre-commit": "eslint . && npm test", } } }

Conclusion

Dans cet article, nous avons découvert que différentes actions effectuées sur un référentiel git peuvent éventuellement déclencher l'exécution de scripts personnalisés. Ces scripts peuvent être sous le contrôle du développeur localement ou gérés de manière plus centralisée pour une équipe ou un projet sur une télécommande. Nous avons également appris que les scripts sont souvent écrits dans un script shell comme bash, mais peuvent en fait utiliser presque n'importe quel langage de script, même JavaScript.

Les crochets Git peuvent être une partie très puissante d'un flux de travail bien conçu, et je vous encourage à les essayer et à voir ce que vous pouvez faire pour vos propres projets.