Conventional Commits et Husky

Husky

Husky est un outil qui permet d'utiliser des Git hooks plus facilement.

Que sont les Git hooks ?

Les Git hooks sont des scripts qui s'exécutent avant ou après des événements Git comme commit, push, etc. Ils permettent d'automatiser des tâches comme :

• Vérifier le formatage du code avant un commit
• Exécuter des tests avant un push
• Valider la syntaxe des messages de commit

Installation de Husky

npm install --save-dev husky
npx husky init

Création d'un hook pre-commit

Le hook pre-commit s'exécute avant qu'un commit ne soit finalisé. C'est l'endroit idéal pour vérifier la qualité du code. Créer le fichier .husky/pre-commit avec le contenu suivant :

npm run lint && npm run format

Conventional Commits

Les "Conventional Commits" (commits conventionnels) constituent une spécification pour ajouter une signification sémantique aux messages de commit. Cette convention standardisée facilite :

• La génération automatique de changelogs
• La détermination automatique de versions sémantiques (SemVer)
• La communication claire des changements aux coéquipiers et utilisateurs
• Le déclenchement de processus de build et de déploiement appropriés

Structure d'un Conventional Commit

Un message de commit conventionnel a la structure suivante :

<type>[scope optional]: <description>

[optional body]

[optional footer(s)]

Type

Le type définit la nature du changement et fait partie des catégories suivantes :

• feat : Ajout d'une nouvelle fonctionnalité
• fix : Correction d'un bug
• docs : Modification de la documentation
• style : Changements qui n'affectent pas le sens du code (espaces, formatage, etc.)
• refactor : Changement de code qui ne corrige pas un bug et n'ajoute pas de fonctionnalité
• perf : Amélioration des performances
• test : Ajout ou correction de tests
• build : Changements qui affectent le système de build ou les dépendances externes
• ci : Changements dans la configuration CI ou les scripts
• chore : Autres changements qui ne modifient pas les fichiers src ou test
• revert : Annulation d'un commit précédent

Scope

Le scope est optionnel et indique la partie du code affectée par le changement (par exemple, auth, api, db).

Description

Une description concise du changement au présent. Ne pas capitaliser la première lettre et ne pas mettre de point à la fin.

Body

Le corps est optionnel et fournit des détails supplémentaires sur le changement. Il doit commencer par une ligne vide après la description.

Footer

Le footer est optionnel et peut contenir des références à des issues, des notes sur les changements non rétrocompatibles (breaking changes), etc.

Exemples de Conventional Commits

feat(auth): ajouter la fonction de réinitialisation de mot de passe

Cette fonctionnalité permet aux utilisateurs de réinitialiser leur mot de passe via un email de confirmation.

Closes #123

fix: corriger le bug d'authentification lors de la connexion avec Google

docs: mettre à jour la documentation de l'API REST

feat: ajouter la fonction de recherche avancée

BREAKING CHANGE: L'ancienne API de recherche n'est plus compatible.

Installation et configuration de commitlint

Pour vérifier que les messages de commit suivent la convention des Conventional Commits, nous pouvons utiliser commitlint :

npm install --save-dev @commitlint/{cli,config-conventional}

Créez un fichier commitlint.config.js à la racine de votre projet :

export default { extends: ['@commitlint/config-conventional'] }

Ajoutez un hook commit-msg pour valider le message de commit :

npx commitlint --edit $1

Avantages de cette approche

L'utilisation de Conventional Commits avec Husky présente plusieurs avantages :

• Histoire de projet plus lisible : Les messages de commit standardisés facilitent la compréhension de l'historique du projet.
• Génération automatique de changelogs : Les outils comme semantic-release peuvent générer automatiquement des notes de version basées sur les messages de commit.
• Versioning sémantique automatique : Le type de changement (feat, fix, etc.) peut déterminer automatiquement la prochaine version.
• Qualité du code améliorée : Les vérifications pré-commit garantissent que seul le code de qualité est commité.
• Réduction des erreurs : Les vérifications automatiques réduisent le risque d'erreurs humaines.

En standardisant les messages de commit et en automatisant les vérifications, vous simplifiez la collaboration et améliorez la qualité globale de votre projet.