Installer pre-commit et déclencher un blocage

Ce que vous allez faire

Ce module ne dépend pas du précédent (le module 4, sur la lecture de devcontainer.json) : c'est un second sujet indépendant, qui ne touche ni à Docker ni aux Dev Containers. Vous allez installer l'outil pre-commit, le configurer avec un seul hook simple, puis provoquer volontairement un commit bloqué pour voir, de vos propres yeux, ce que ça donne — exactement le scénario décrit au module 2.

Prérequis : le module 1 doit être vert (git installé et configuré). Vous avez aussi besoin de Python 3 avec pip disponibles sur votre machine — la plupart des systèmes récents les ont déjà. Si ce n'est pas le cas, installez Python depuis python.org, ou utilisez pipx si vous préférez isoler l'installation dans son propre environnement.

Étape 1 — installer pre-commit

pip install pre-commit

Alternative avec pipx, si vous préférez ne pas installer d'outils Python globalement :

pipx install pre-commit

Vérification :

pre-commit --version

Sortie saine attendue : un numéro de version, par exemple pre-commit 4.6.0 — la valeur exacte n'a pas d'importance, seul le fait d'obtenir un numéro (et pas une erreur) compte.

Étape 2 — créer un dépôt git pour l'exercice

mkdir mon-projet-pre-commit
cd mon-projet-pre-commit
git init

Sortie attendue :

Initialized empty Git repository in .../mon-projet-pre-commit/.git/

Si git n'a jamais servi sur cette machine, quelques lignes hint: sur le nom de branche par défaut peuvent s'afficher avant cette ligne — ignorez-les, ce n'est pas une erreur.

Étape 3 — écrire .pre-commit-config.yaml

À la racine de ce dossier, créez un fichier .pre-commit-config.yaml avec exactement ce contenu :

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v6.0.0
    hooks:
    -   id: trailing-whitespace

Ce que dit ce fichier : repos est une liste de dépôts sources de hooks. Ici, un seul dépôt, pre-commit/pre-commit-hooks — une collection officielle de hooks génériques. rev fige la version exacte (le tag v6.0.0) de ce dépôt à utiliser, pour que la configuration soit reproductible d'une machine à l'autre, comme discuté au module 2. hooks liste les hooks à activer parmi ceux que ce dépôt propose ; ici un seul, identifié par id: trailing-whitespace, qui détecte (et corrige) les espaces en fin de ligne.

Étape 4 — installer le hook git

pre-commit install

Sortie attendue :

pre-commit installed at .git/hooks/pre-commit

Cette commande écrit un script dans .git/hooks/pre-commit, le hook natif que git exécute automatiquement avant chaque commit dans ce dépôt. Vous inspecterez ce script en détail au module suivant — pour l'instant, retenez juste qu'il existe et qu'il est désormais actif.

Étape 5 — provoquer un blocage

Créez un fichier avec une ligne se terminant par des espaces superflus :

printf 'bonjour tout le monde   \n' > exemple.txt

Stagez-le et tentez de le commiter :

git add exemple.txt
git commit -m "ajout exemple"

Sortie attendue — le commit est refusé :

Trim Trailing Whitespace.................................................Failed
- hook id: trailing-whitespace
- exit code: 1
- files were modified by this hook

Fixing exemple.txt

Ce qui s'est passé : le hook trailing-whitespace a inspecté exemple.txt, a retiré les espaces en fin de ligne directement sur le fichier sur disque, puis a rendu un code de sortie différent de zéro parce qu'il a modifié quelque chose. Un hook qui rend un code de sortie non nul fait échouer toute la vérification, et git annule le commit — le contenu original (avec les espaces en trop) n'entre jamais dans l'historique.

Vérifiez-le :

git status

Vous verrez exemple.txt apparaître deux fois : sous « Changes to be committed » (la version originale, toujours en attente dans l'index) et sous « Changes not staged for commit » (la version corrigée par le hook, sur disque). C'est normal : le commit n'a jamais eu lieu, donc l'index garde l'ancienne version, tandis que le hook a modifié le fichier sur disque après coup.

Étape 6 — corriger et recommiter

Le fichier est déjà corrigé sur disque (c'est le hook qui l'a fait). Il ne reste qu'à le re-stager et recommiter :

git add exemple.txt
git commit -m "ajout exemple"

Cette fois, le hook passe :

Trim Trailing Whitespace.................................................Passed

Et le commit est accepté :

[main (root-commit) a1b2c3d] ajout exemple
 1 file changed, 1 insertion(+)
 create mode 100644 exemple.txt

(Le nom de branche affiché — main ou master — dépend de la configuration init.defaultBranch de votre machine ; les deux sont normaux, seul le reste de la ligne compte.)

Ce que vous venez de faire

Vous avez installé pre-commit, écrit une configuration minimale pointant vers un hook officiel et versionné, activé le hook git qui l'exécute, puis constaté en pratique — pas en théorie — qu'un commit contenant un problème détectable est refusé avant d'entrer dans l'historique. C'est exactement le garde-fou décrit au module 2 : rien de cassé ne part jamais dans le dépôt partagé sans passer par cette vérification.

Au module suivant, vous ouvrez le fichier .git/hooks/pre-commit généré à l'étape 4 pour comprendre ce qu'il contient réellement, et en quoi il diffère d'un hook git natif que vous auriez écrit vous-même.