← Blog · 9 avril 2026 · L'équipe ConvertCaseHQ · 8 min de lecture

Rédiger des messages de commit Git propres, avec une casse cohérente

Un message de commit Git propre commence par une ligne de sujet courte (visez 50 caractères), écrite à l'impératif (en anglais, « Add » plutôt que « Added »), sans point final. Vient ensuite une ligne vide, puis un corps coupé à 72 caractères qui explique pourquoi la modification a été faite. Pour les majuscules, choisissez une convention et tenez-vous-y : avec un préfixe comme feat: ou docs:, le mot qui suit est en général en minuscule ; sans préfixe, le conseil classique est de mettre une majuscule au premier mot.

Git n'impose rien de tout cela lui-même, et c'est pourquoi les historiques dérivent. Voici les règles, l'origine de chacune, et comment faire vérifier le tout par vos outils pour ne plus avoir à vous en souvenir.

L'anatomie d'un bon message de commit

fix(editor): keep cursor position after paste

Pasting into an empty textarea moved the cursor to the start, because
the change handler replaced the value before restoring the selection.
Restore the selection after updating the value instead.

Fixes #142

Trois parties : un sujet qui dit ce que fait le commit, un corps qui dit pourquoi, et des pieds de message (footers) facultatifs pour les références et les métadonnées. La documentation de Git elle-même recommande de commencer par « a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description » (une seule ligne courte, de 50 caractères au maximum, qui résume la modification, suivie d'une ligne vide puis d'une description plus détaillée). Tout ce qui précède la première ligne vide est traité comme le titre du commit : c'est ce qu'affichent git log --oneline, git shortlog et git format-patch.

La ligne de sujet : courte, à l'impératif, sans point final

Cinquante caractères, c'est une limite souple. Le guide SubmittingPatches du projet Git la qualifie exactement ainsi et demande aux contributeurs de « skip the full stop » (omettre le point final). Si vous n'arrivez pas à descendre sous 50, c'est souvent le signe que le commit fait deux choses.

Le même guide demande de « describe your changes in imperative mood » (décrire vos modifications à l'impératif), comme si vous donniez des ordres au code : « make xyzzy do frotz », et non « makes xyzzy do frotz » ni « changed xyzzy to do frotz ». Un test pratique, tiré des sept règles de Chris Beams pour les messages de commit : un bon sujet complète la phrase « If applied, this commit will … » (si on l'applique, ce commit va …).

• « If applied, this commit will add CSV export » fonctionne.
• « If applied, this commit will added CSV export » ne fonctionne pas.
• « If applied, this commit will bug fixes » ne fonctionne pas non plus, et n'apprend rien au lecteur.

L'impératif correspond aussi aux messages que Git écrit pour vous, comme Merge branch 'main' et Revert "…", si bien que vos propres commits se lisent de la même façon dans l'historique.

Majuscule ou non au début du sujet : les deux camps

C'est là que les conseils se contredisent vraiment, et la bonne réponse dépend de la présence ou non d'un préfixe au début de vos sujets.

La version du projet Git comporte un détail à imiter. Seul le premier mot après le préfixe perd sa majuscule, et uniquement parce que c'est le premier mot : les mots qui prennent toujours une majuscule la gardent. Son propre exemple est refs: HEAD is also treated as a ref, puisque HEAD s'écrit toujours en capitales. La même logique donne fix: handle iOS paste et docs: update README badges.

Notre avis : avec un préfixe, mettez le premier mot en minuscule, sauf s'il s'agit d'un nom ou d'un sigle. Sans préfixe, mettez une majuscule au premier mot. Mélanger les styles est la seule vraie erreur, car git log --oneline transforme vos sujets en liste, et une liste qui change de casse toutes les quelques lignes fait négligé. Pour le même raisonnement appliqué à la documentation, consultez notre guide pour rédiger une documentation cohérente.

Ce que dit vraiment la spécification Conventional Commits

La spécification Conventional Commits 1.0.0 définit cette structure :

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Les règles essentielles, en bref :

• feat (une nouvelle fonctionnalité) et fix (une correction de bogue) sont les deux types que définit la spécification ; ils correspondent aux versions MINOR et PATCH du Semantic Versioning, les changements incompatibles (breaking changes) correspondant à MAJOR. D'autres types sont permis ; la spécification mentionne build, chore, ci, docs, style, refactor, perf et test, tels que les recommande la configuration conventional de commitlint, qui s'appuie sur la convention d'Angular.
• Un changement incompatible se signale par un ! avant les deux-points (feat!: drop Node 16 support) ou par un pied de message BREAKING CHANGE:, qui doit être en capitales.
• Les outils qui lisent ce format ne doivent pas le traiter comme sensible à la casse, sauf pour BREAKING CHANGE. À la question de savoir si les types doivent être en minuscules ou en majuscules, la FAQ de la spécification répond que n'importe quelle casse peut être utilisée, « but it's best to be consistent » (mais mieux vaut rester cohérent).

La spécification ne fixe aucune longueur de sujet et n'exige pas l'impératif. Cela vient des conventions de Git.

Là où commitlint est plus strict que la spécification

@commitlint/config-conventional, de commitlint, est le moyen habituel d'imposer ce format, et ses valeurs par défaut vont plus loin que la spécification. Nous avons fait passer des exemples de sujets dans la version 21 :

C'est la ligne README qu'il faut surveiller. Un sujet qui commence par un sigle ou un nom de classe, comme fix: README typo ou feat: URLSearchParams support, est rejeté, alors que le projet Git accepterait l'équivalent. Reformulez pour que le sigle ne vienne pas en premier, ou assouplissez la règle subject-case dans votre configuration. La limite par défaut de l'en-tête est de 100 caractères : commitlint ne vous tiendra donc pas non plus à 50.

Le corps : coupez à 72 caractères et expliquez pourquoi

Git ne remet jamais votre message en forme. L'explication de Tim Pope, en 2008, reste valable : git log indente les messages de quatre espaces ; sur un terminal de 80 colonnes, quatre de plus par symétrie à droite laissent 72 colonnes, et un texte coupé reste aussi lisible quand les commits sont envoyés par e-mail avec git format-patch. Notre outil Couper le texte à N caractères mettra un paragraphe en forme à 72 caractères, en coupant entre les mots, si votre éditeur ne le fait pas.

Réservez le corps à ce que le diff ne peut pas montrer : le problème, la raison de ce correctif, et tout ce que vous avez essayé sans succès. En ligne de commande, chaque -m devient son propre paragraphe : git commit -m "fix: keep cursor after paste" -m "Pasting into…" produit donc un sujet, une ligne vide et un corps.

Laissez vos outils faire la vérification

• VS Code : activez "git.inputValidation": true. La zone de message de commit avertit alors quand le sujet dépasse 50 caractères (git.inputValidationSubjectLength) ou qu'une autre ligne dépasse 72 (git.inputValidationLength).
• Vim : ses réglages intégrés pour les messages de commit coupent le corps à 72 caractères (textwidth=72) et cessent de surligner le sujet après 50 caractères.
• Un modèle de commit : git config commit.template ~/.gitmessage ouvre chaque commit dans l'éditeur avec vos rappels déjà en place.
• Un hook commit-msg pour des vérifications sans dépendances. Enregistrez ceci sous .git/hooks/commit-msg et rendez-le exécutable :

#!/bin/sh
# Checks the subject line of every commit message.
subject=$(head -n 1 "$1")
length=${#subject}   # counts bytes in some shells; fine for ASCII subjects

if [ "$length" -gt 72 ]; then
  echo "commit-msg: subject is $length characters (limit 72, aim for 50)" >&2
  exit 1
fi
if [ "$length" -gt 50 ]; then
  echo "commit-msg: note, subject is $length characters (aim for 50)" >&2
fi
case "$subject" in
  *.) echo "commit-msg: drop the full stop at the end of the subject" >&2
      exit 1 ;;
esac
if [ -n "$(sed -n 2p "$1")" ]; then
  echo "commit-msg: leave line 2 blank, between subject and body" >&2
  exit 1
fi

Il avertit au-delà de 50 caractères, rejette un sujet de plus de 72 caractères, un point final ou l'absence de ligne vide, et git commit --no-verify le contourne quand c'est vraiment nécessaire. Pour un comptage rapide avant de valider, collez le sujet dans notre Compteur de caractères.

La liste de contrôle, donc : un sujet à l'impératif, d'environ 50 caractères, sans point final, une seule règle de majuscules pour tout le dépôt, une ligne vide, un corps coupé à 72 caractères qui explique pourquoi, et un hook ou un linter pour que les règles survivent à une semaine chargée.