Crochets Git

Git est un puissant système de contrôle de version dont nous avons à peine effleuré la surface au cours de nos derniers articles. Aujourd'hui, nous allons examiner la puissance d'automatisation que Git peut vous offrir avec les Git Hooks.

Chaque référentiel obtient des crochets intégrés lorsque vous utilisez la commande git init . Lorsqu'un référentiel est initialisé, vous obtenez un répertoire .git caché et à l'intérieur se trouve un répertoire appelé hooks qui contiendra tous vos hooks. Ouvrez n'importe quel référentiel git que vous avez sous la main et utilisez ls -a pour voir le répertoire caché, puis ouvrez-le dans votre éditeur de code préféré.

Pour commencer, vous verrez un tas de fichiers avec des extensions de fichier .sample . Ce sont exactement ce qu'ils disent, des exemples de scripts que vous pourriez utiliser dans vos projets. Les fichiers sont nommés pour correspondre au hook sur lequel ils s'exécutent. Ainsi, post-commit.sample s'exécute sur le hook post-commit .

Vous pouvez utiliser à peu près n'importe quel langage pour écrire un crochet. Le fichier est analysé selon la notation shebang en haut du fichier. Si vous vouliez utiliser node, vous utiliseriez #! /usr/bindi/env node #! /usr/bindi/env node et votre fichier sera analysé comme un fichier de nœud.

Avant de nous plonger dans ce que vous pouvez faire avec les crochets git, jetons un coup d'œil à certains des crochets qui sont à votre disposition.

Types de crochets Git

Crochets de workflow de validation

pre-commit est exécuté avant même que vous n'entriez votre message de validation et il peut être contourné avec git commit --no-verify .

prepare-commit-msg peut être utilisé pour modifier le message par défaut que vous voyez dans votre message de validation. Utilisez-le pour donner des instructions aux développeurs sur le type de message de validation qu'ils doivent laisser. Il peut également être utilisé pour automatiser le contenu de l'endroit où le message est automatiquement généré pour vous, comme les fusions ou pour ajouter automatiquement un numéro de problème à votre message de validation.

commit-msg peut être utilisé pour valider le message de validation de votre projet. Peut-être que vous ne voulez pas que quiconque puisse mettre un message de validation qui dit simplement "traiter les espaces blancs". Vous pouvez utiliser ce crochet pour détecter la présence des mots espace blanc, puis quitter et avertir l'utilisateur qu'il a besoin d'un meilleur message de validation.

post-commit s'exécute après tous les crochets de validation ci-dessus. C'est très utile pour une notification qu'un commit a été fait.

Crochets clients

post-checkout s'exécute après que vous avez exécuté une commande git checkout réussie. Si vous aviez un ensemble de fichiers volumineux utilisés sur le site mais que vous ne les vouliez pas dans le contrôle de code source, vous pouvez utiliser cette commande pour déplacer les fichiers à votre place.

pre-push s'exécute pendant une commande git push avant que des objets ne soient transférés vers le référentiel distant.

Crochets de serveur

pre-receive s'exécute lorsqu'un client a poussé du code vers un référentiel distant. Cela peut être utilisé pour vérifier le code qui est poussé pour s'assurer qu'il répond aux critères de votre projet avant d'accepter la poussée.

post-receive s'exécute une fois que votre référentiel distant a reçu les mises à jour. Cela peut être utilisé pour appeler un crochet Web qui déclenche un processus de déploiement ou pour notifier à une salle de discussion qu'un commit a été reçu et est prêt à être examiné.

La plupart des crochets ci-dessus peuvent être configurés pour s'exécuter uniquement sur des branches spécifiques. Cela peut signifier que lorsque vous utilisez un crochet post-receive uniquement lorsque quelqu'un a envoyé du code à la branche principale censée être prête à être déployée. Une liste de développeurs pourrait être notifiée pour examiner le code, puis le déployer. De cette façon, vous auriez toujours 2 paires d'yeux sur un déploiement, ce qui peut signifier attraper des erreurs qu'un seul développeur peut facilement manquer.

J'ai sauté certains des crochets qui sont disponibles parce que je n'ai jamais vu le besoin de les utiliser. Un ensemble de crochets dont je n'ai pas parlé est celui des crochets de flux de travail de messagerie. Si vous n'acceptez pas les correctifs de votre code par e-mail, vous n'en aurez probablement jamais besoin. Vous pouvez trouver tous les crochets disponibles dans la documentation.

En pratique, les crochets que j'ai le plus utilisés sont:

• pré-commit
• pré-poussée
• commit-msg
• pré-réception
• post-commit
• post-réception

Faisons maintenant quelque chose avec ces crochets.

Activer un plugin WordPress avec WP Cli et Git Hooks

Pour un projet client cette année, j'ajoutais un magasin et j'effectuais encore quelques tâches sur le site principal. Cela signifiait que le site principal n'avait aucun de nos plugins WooCommerce installé ou activé. J'avais besoin de développer la boutique WooCommerce sur une branche et ce n'est qu'une fois que j'étais prêt à tout mettre en ligne que j'ai voulu déplacer WooCommerce vers la branche principale.

Pour commencer, nous aurons besoin d'une nouvelle branche appelée magasin. Nous pouvons l'obtenir en utilisant git checkout -b store . Cela crée une nouvelle branche et la vérifie pour nous. Maintenant, préparons le crochet.

Nous devons d'abord créer le hook post-checkout avec cette commande touch .git/hooks/post-checkout .

Ensuite, nous devons le rendre exécutable. Nous pouvons le faire avec la commande chmod du terminal chmod +x .git/hooks/post-checkout .

Ouvrez maintenant le fichier dans l'éditeur de code de votre choix et copiez le code ci-dessous dans votre fichier post-checkout .

#! /bin/bash

wp plugin activate woocommerce

echo "activated WooCommerce"

wp plugin activate automatewoo

echo "activated AutomateWoo"

Vous pouvez en faire la démonstration en passant à n'importe quelle branche via un terminal. Vous devriez voir deux lignes vous indiquant que WooCommerce et AutomateWoo ont été activés. Nous savons que cela fonctionne, mais ce n'est pas tout à fait ce que nous voulons car cela activera les plugins à chaque fois que nous changerons de branche.

Ce que nous voulons vraiment, c'est les activer lorsque nous nous déplaçons dans notre succursale de magasin, puis les désactiver lorsque nous sommes sur notre succursale principale. Pour ce faire, nous aurons besoin du crochet pour détecter à quelle branche nous appartenons. Échangez le contenu de post-checkout avec le code ci-dessous.

#! /bin/bash

oldrev=$1
newrev=$2

branch_name="(git symbolic-ref HEAD 2>/dev/null)"

if [ "refs/head/store" = "$branch_name" ];then
wp plugin activate woocommerce
echo "activated Woo"

wp plugin activate automatewoo
echo "activated AutomateWoo"
fi

if [ "refs/head/main" = "$branch_name" ];then
wp plugin deactivate woocommerce
echo "deactivated Woo"

wp plugin deactivate automatewoo
echo "deactivated AutomateWoo"
fi

Ce code commence par affecter la branche que nous vérifions à la variable branch_name . Ensuite, nous avons deux instructions if. Les premières vérifications pour voir si nous avons déménagé à la succursale du magasin. Si nous l'avons, il utilise WP CLI pour activer WooCommerce et AutomateWoo.

La prochaine instruction if vérifie si nous sommes sur la branche principale. Si nous le sommes, il désactivera les plugins avec WP CLI et nous en informera dans le terminal.

Contrôler les flux de travail Git avec des crochets Git

Dans un article précédent sur Git, j'ai parlé de différents workflows Git. Un cas d'utilisation très courant des crochets consiste à empêcher quiconque de valider du code directement dans la branche principale. Vous pouvez utiliser un crochet pour vous assurer que tout le code est fusionné d'une branche différente dans main.

Commencez par renommer pre-commit.sample en pre-commit , puis rendez-le exécutable comme je l'ai décrit ci-dessus. Saisissez ensuite le code ci-dessous et utilisez-le dans le fichier de pré-commit.

#! /bin/bash

username=$GIT_AUTHOR_NAME
branch="$(git symbolic-ref HEAD 2>/dev/null)"

if [ "$branch" = "refs/heads/main" ]; then
echo "WHOA that was '"${branch}"' you should not do that. Stop doing silly stuff and create your own branch and merge it."
exit 1 # if you remove this it won't block the commit but it will send the message to slack
fi

Cela vérifie si nous sommes sur la branche principale, et si nous le sommes, le commit est arrêté. Ensuite, il imprime un rappel à l'utilisateur qu'il ne doit pas s'engager directement dans la branche principale.

N'oubliez pas que de nombreux endroits deviennent main comme succursale. Les projets plus anciens peuvent nécessiter master en place ici s'ils n'ont pas été mis à jour.

Vous pouvez même aller plus loin et utiliser cURL pour accéder à l'API d'une application de chat, puis vous plaindre publiquement que quelqu'un a tenté de s'engager sur main.

Les seules limites des crochets git sont votre imagination. Vous pouvez les utiliser pour empêcher quelqu'un de s'engager si un TODO est présent dans son code ou pour arrêter les espaces à la fin d'un fichier.

Si vous avez une partie de votre flux de travail qui est une pierre d'achoppement continuelle, regardez les crochets pour l'automatiser, afin que vous n'ayez pas à vous en souvenir.