Fermer

décembre 2, 2019

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


À propos de l'auteur

Konstantinos est un ingénieur en logiciel basé à Londres. Il travaille actuellement pour DAZN, un service multimédia de diffusion sportive en direct et à la demande. Snowboarder passionné…
Plus d'informations sur
Konstantinos

Les flux de travail de développement peuvent facilement devenir incontrôlables et commencer à causer de la confusion et des frictions au sein des équipes, notamment à mesure qu'elles s'agrandissent. Il est arrivé trop souvent que notre révision de code ne remarque que la virgule manquante ou les tests infructueux qui ne s'exécutent jamais avant d'être transférés vers un référentiel distant. Heureusement, il existe des outils qui peuvent dissiper ces frictions, simplifier le flux de travail des développeurs et nous aider à nous concentrer sur les tâches les plus importantes. Grâce à git et aux crochets qu’il fournit, nous disposons d’une grande variété d’automatisations avec lesquelles nous pouvons configurer notre flux de travail de développement et nous simplifier la vie.

L’une des exigences majeures pour une équipe ou un projet open source est d’utiliser un système de contrôle de version (VCS). Git est un système de contrôle de version distribué gratuit et à source ouverte permettant de suivre les modifications du code source au cours du développement du logiciel. Il a été créé par Linus Torvalds en 2005 pour le développement du noyau Linux. Il est facile à apprendre et a une empreinte minuscule à la rapidité d'exécution .

Il y a de grandes chances que vous ayez déjà utilisé Git (car c'est l'un des logiciels les plus populaires et outils VCS bien adoptés disponibles dans la communauté de développement), et vous avez probablement déjà une certaine connaissance de la mise en scène et de la validation de votre code en le déplaçant depuis un référentiel distant. Cet article ne traitera pas des bases des workflows git, mais se concentrera principalement sur les crochets git et sur la façon de les utiliser afin d’améliorer la collaboration au sein de votre équipe. Avec la taille croissante des équipes, il est de plus en plus important de garder les contributeurs en ligne et de maintenir différentes règles concernant le code.

Que sont les crochets Git?

Les scripts Git hook sont des scripts déclenchés lorsque des actions ou des événements spécifiques sont exécutés dans un dépôt git. Ces actions concernent des parties du flux de travaux du contrôle de version, telles que la validation et la diffusion. Les crochets peuvent être vraiment utiles en automatisant des tâches sur votre flux de travail git. Par exemple, ils peuvent nous aider à valider la syntaxe de notre base de code en fonction de règles spécifiques ou à effectuer des tests avant de valider nos modifications.

How To Get Them Set?

Les hooks Git sont une fonctionnalité intégrée qui signifie que nous sommes en mesure d’y accéder et de 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 configurer.

Créez un nouveau référentiel git avec votre terminal favori.

 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 des informations relatives au référentiel, telles que les hachages de contrôle de version, des informations sur les validations, les adresses de référentiels distants, etc. C'est aussi le dossier où les hooks vivent pour git .git / hooks . Vous pouvez trouver des exemples de scripts préremplis créés automatiquement 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 exemples que vous pouvez trouver sont les suivants:

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

Under The Hood

Maintenant que nous savons où trouver des points d'ancrage, prenons un peu de recul pour comprendre comment ils fonctionnent réellement.

Les hooks Git sont basés sur des événements, aussi longtemps que nous exécutons une commande git dans le flux de développement, git vérifiera les dossiers des hooks afin de déterminer si un script associé doit être exécuté. Certains de ces scripts seront exécutés avant ou après ces actions de flux de développement.

Un bon exemple que nous devons parcourir et comprendre plus précisément le flux sous lequel les crochets sont déclenchés est le flux de travail de validation, qui est un cas d'utilisation assez familier. [19659005] Chaque fois que nous apportons des modifications à notre base de code, certains de ces points d'ancrage connexes sont déclenchés dans l'ordre suivant:

  1. pre-commit : inspecte l'instantané qui est sur le point d'être commis et vérifie ce qui doit être commis. ] prepare-commit-msg : permet de modifier le message par défaut avant que l'auteur ne l'ait vu.
  2. commit-msg : définit le message de validation dans un modèle.
  3. post-commit : exécute une action juste après la validation, et envoie une notification par exemple.
 Crochets s'exécutant pendant le processus de création de validation
Crochets s'exécutant pendant le processus de création de validation (Crédits image: Atlassian Bitbucket ) ( Large p review )

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 hooks git.

 nano .git / hooks / pre-commit

Ajoutez l'extrait suivant:

 #! / Bin / sh
echo Des changements sont sur le point d'être engagés

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 Des modifications ont été validées
 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'informer les validateurs HTML).

Bonjour tout le monde depuis notre nouveau référentiel !

Nous ajouterons les modifications apportées à notre base de code par le biais de la mise en scène, puis nous engagerons ceci:

 git add.
git commit

Une fois que l'engagement a été traité avec succès, vous pouvez voir la sortie suivante des deux scripts ajoutés ci-dessus:

 Des modifications sont sur le point d'être validées.
Les modifications ont été validées

Comme prévu, Git a déclenché des crochets dans le flux de validation. Les scripts pré-commit et post-commit 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).

une démonstration simple afin de comprendre le fonctionnement des scripts de flux de production validés et leur exécution. Pour plus de détails sur ce flux de travail, vous pouvez en lire 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 hooks pouvant ê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 shebang correct à la première ligne de notre script exécutable.

Par exemple, nous pouvons réécrire le crochet pre-commit comme nœud. js script comme ci-dessous:

 #! / usr / bin / env node
console.log ("Les modifications sont sur le point d'être validées")

Crochets locaux et distants

Les crochets sont séparés entre local et distant (ou client et serveur). Tandis que les points d'ancrage locaux s'exécutent avant ou après des actions spécifiques sur le référentiel local, les points d'ancrage distants s'exécutent avant ou après les envois au serveur. Les stratégies locales ne peuvent pas être utilisées pour appliquer des stratégies car leur nature permet aux développeurs de les modifier facilement. Ils sont principalement utilisés pour coller à certaines directives spécifiques que nous souhaitons appliquer au sein d'une équipe. Si nous voulons être plus stricts et appliquer certaines règles à notre référentiel, nous résidons dans des hooks distants.

Local Hooks

  • pre-commit
  • prepare-commit-msg
  • -msg
  • post-commit
  • applypatch-msg
  • pre-applypatch
  • post-applypatch
  • pré-rebase
  • post-réécriture
  • post-checkout
  • après la fusion
  • pré-push

Hooks distants

  • pré-reçu
  • mise à jour
  • post-réception

Crochets de partage

Les crochets de sort servent à les partager au sein de l'équipe. C’est leur raison principale: promouvoir une meilleure collaboration d’équipe, automatiser des processus néfastes et nous concentrer uniquement sur les parties importantes de la base de code.

Comme indiqué précédemment, .git / hooks est le dossier Cela héberge nos points d'ancrage 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 solution pour résoudre ce problème consiste à ajouter tous nos points d'ancrage personnalisés sur un site distinct. dossier dans notre référentiel. Par exemple, nous pouvons ajouter un dossier .githooks et enregistrer les scripts exécutables là-bas. Ensuite, lors de l’initialisation du projet, nous pouvons soit copier explicitement, soit faire un lien symbolique entre ces scripts et le dossier d’origine pour conserver nos crochets .git / hooks .

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

Si vous utilisez la dernière version de Git (parlant de 2.9 et des versions ultérieures), nous sommes en mesure de configurer directement le chemin des crochets git dans notre dossier personnalisé:

 git config core.hooksPath .githooks

Git Hooks Made Easy (cas d'utilisation de JavaScript Codebase)

Il existe des outils qui nous aident à intégrer davantage les hooks Git aux besoins de notre base de code. En particulier 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 infiltrer notre code ou exécuter des tests dans la version précédente . commit et engagez-vous en fonction de la réussite du test, des tests ou des deux.

Pour ce faire, vous pouvez étendre la configuration du package.json simplement comme suit:

 {
    "scripts": {
        "test": "echo Exécution de tests"
    },
    "devDependencies": {
        "eslint": "5.16.0",
    },
    "husky": {
        "crochets": {
            "pre-commit": "eslint. && npm test",
        }
    }
}

Conclusion

Dans cet article, nous avons découvert que différentes actions prises 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 distant. Nous avons également appris que les scripts sont souvent écrits dans un script shell comme bash, mais peuvent en réalité utiliser presque tous les langages de script, même JavaScript.

Les hooks Git peuvent être un élément très puissant d'un flux de travail bien conçu. d vous encourage à les essayer et à voir ce que vous pouvez faire pour vos propres projets.

 Smashing Editorial (dm, il)




Source link