Modèles de message de commit Git

Modèles de message réutilisables type Conventional Commits et prêts pour les PR qui se déploient dans votre terminal et votre éditeur.

Présentation de la catégorie de modèle

Des messages de commit cohérents rendent l'historique d'un dépôt lisible, permettent des changelogs automatisés et accélèrent la revue de code — mais taper à la main un Conventional Commit bien structuré à chaque fois est assez fastidieux pour que la plupart des développeurs se rabattent sur des résumés d'une ligne. Un expandeur de texte résout cela en transformant un déclencheur court en une ossature de commit complète avec le type, le scope, le résumé, le corps et le pied déjà disposés, de sorte que vous remplissez les détails au lieu de retenir le format. Comme Lightning Assist fonctionne à l'échelle du système — y compris dans le terminal, où se font la plupart des commits, et dans la zone de commit de VS Code — les mêmes modèles fonctionnent que vous committiez depuis la ligne de commande, votre IDE ou une GUI Git. La voix Push-to-Talk peut même dicter le paragraphe plus long du corps quand vos mains sont loin du clavier en plein débogage.

Quand utiliser ces modèles

Utilisez des modèles de message de commit à chaque commit, mais ils rapportent le plus sur les commits qui comptent plus tard : les corrections de bugs que vous reviendrez voir, les breaking changes qui touchent d'autres équipes et tout commit dans un dépôt qui génère automatiquement des releases ou des changelogs à partir de l'historique. Si votre projet utilise Conventional Commits, semantic-release ou toute automatisation de changelog, une ossature cohérente n'est pas qu'une question de propreté — c'est ce qui fait fonctionner la tooling tout court. Même sur des projets en solo, un git log lisible écrit dans un format cohérent fait gagner un temps réel quand vous bisectez une régression ou tentez de vous rappeler pourquoi un changement a été fait il y a six mois.

Exemples de modèles dans cette catégorie

  • Ossature de Conventional Commit : type, scope optionnel, résumé, corps et pied avec référence de ticket.
  • Commit de fix avec contexte du bug : ce qui était cassé, le correctif et l'issue qu'il ferme.
  • Commit de breaking change : le changement plus un pied BREAKING CHANGE clairement marqué pour la tooling de release.

Exemples de modèles en pratique

Ossature de Conventional Commit

Le modèle de tous les jours pour tout commit, suivant la spécification Conventional Commits qui alimente les outils de versionnage et de changelog automatiques. La structure est un type (feat, fix, chore, docs, refactor, test, etc.), un scope optionnel entre parenthèses, un résumé concis à l'impératif sous une cinquantaine de caractères, une ligne vide, puis un corps expliquant le pourquoi, et un pied pour les références de ticket. Gardez ceci sur un déclencheur court comme ;cc pour qu'il se déploie dans le terminal avant que vous n'écriviez le message. Remplir une ossature cohérente à chaque fois est ce qui rend un git log réellement utile des mois plus tard, et c'est la différence entre un outil de release qui peut générer un changelog automatiquement et un qui ne le peut pas.

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

Commit de fix avec contexte du bug

Les commits de correction de bugs sont ceux que votre futur vous a le plus besoin de comprendre, ils méritent donc mieux que « fix bug ». Capturez trois choses : ce qui était cassé (le symptôme observable), ce que fait le correctif et quelle issue il ferme pour que le tracker se mette à jour automatiquement. Le pied « Closes # » est ce qui relie le commit à votre issue tracker et ferme le ticket au merge sur la plupart des plateformes. Gardez ceci sur un déclencheur comme ;fix. Quand vous êtes plongé dans une session de débogage et voulez consigner la cause racine en langage clair, la voix Push-to-Talk vous laisse dicter le corps sans casser le flux, et AI Enhance peut resserrer une explication dictée décousue en un paragraphe net.

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

Commit de breaking change

Quand un commit change une API, un format de configuration ou tout contrat dont dépend d'autre code, le breaking change doit être marqué explicitement pour que la tooling de release déclenche un saut de version majeure et que le changelog avertisse les utilisateurs. Le standard Conventional Commits utilise un pied BREAKING CHANGE: (ou un ! après le type) précisément pour cela. Précisez ce qui a cassé et, surtout, ce que les consommateurs doivent faire pour migrer — un breaking change sans note de migration se transforme en déluge de questions de support. Gardez ceci sur un déclencheur délibéré comme ;ccbreak pour n'y recourir que lorsque vous le pensez vraiment, car mal étiqueter un breaking change est pire que de ne pas l'étiqueter.

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

Comment commencer

Commencez par l'ossature générale de Conventional Commit sur un déclencheur court comme ;cc, avec des variables pour le type, le scope, le résumé, le corps et le ticket. Ajoutez une variante ;fix préremplie avec le type fix et un pied « Closes # », et une variante ;ccbreak avec le pied BREAKING CHANGE pour les rares mais importants commits cassants. Tapez le déclencheur dans votre terminal ou la zone de commit de votre éditeur et il se déploie en ligne au fil de la frappe — sans raccourci, et il fonctionne pareil dans les deux car l'expansion est à l'échelle du système. Quand les ossatures vous semblent naturelles, ajoutez des modèles de description de PR et de réponse de revue de code pour que tout le flux de soumission de changements soit cohérent.

Conseils de pro

  • Gardez la ligne de résumé sous ~50 caractères et à l'impératif (« add », pas « added ») — la plupart de la tooling git et des relecteurs attendent cette convention.
  • Utilisez un pied « Closes #[issue] » sur les commits de fix pour que le merge du changement ferme automatiquement le ticket lié dans votre tracker.
  • Réservez le modèle de breaking change aux vrais changements de contrat et incluez toujours l'étape de migration — une note de rupture sans elle ne crée que de la charge de support.
  • Dictez le corps du commit avec Push-to-Talk quand vos mains sont loin du clavier en plein débogage, puis resserrez la formulation avec AI Enhance.

Utilisez ces modèles dans n'importe quelle application

Créez des extraits réutilisables à partir de ces exemples et exécutez-les avec un accès rapide, des raccourcis de déclenchement ou des améliorations de l'IA.

Commencer l'essai gratuit

Pages et snippets connexes

Explorez les guides, modèles et comparaisons associés à votre flux de travail.