Générateur de commits Git : rédigez de meilleurs commits et messages à partir de n’importe quel diff
Décrivez vos modifications ou collez un diff et obtenez un message de commit clair et professionnel conforme à Conventional Commits. Gratuit, aucun compte requis.
Vous livrez plusieurs PR par jour ?
Avec Pro, même les diffs volumineux couvrant plusieurs fichiers tiennent dans une seule requête, et les réponses arrivent plus vite.
Aide au code illimitée - Gratuite pendant 7 jours
Générations illimitées, modèles d'IA premium, contexte étendu et historique enregistré. Aucun débit aujourd'hui, résiliez à tout moment.
- Utilisation illimitée
- Modèles premium
- Sans publicité
- Essai gratuit de 7 jours
- Résiliable à tout moment
Générateur de messages de commit Git par IA respectant Conventional Commits
Un bon message de commit explique au prochain développeur (et à votre futur vous) pourquoi une modification a été faite, pas seulement quels fichiers ont changé. Le diff montre déjà les modifications. Le message de commit apporte le contexte, la motivation et facilite les recherches. Notre générateur d’IA produit des messages de commit conformes à la spécification Conventional Commits - avec le bon type (feat, fix, refactor, chore), un périmètre précis et un objet concis de moins de 72 caractères.
Collez la sortie de git diff --staged pour le résultat le plus précis, ou décrivez vos modifications en anglais courant. L’IA déduit le type approprié et rédige un message de commit que vous pouvez utiliser en toute confiance. Pour examiner le code associé au commit, essayez notre Outil d’explication du code. Pour tester le code avant de le committer, utilisez notre Générateur de tests unitaires.
Types de commits générés
Pourquoi de bons messages de commit sont importants
Un historique de commits retrace les décisions prises. Si quelque chose tombe en panne dans six mois, la personne chargée du débogage consultera git blame et git log pour comprendre pourquoi le code a été écrit d’une certaine façon.
Conventional Commits rend git log --grep utile. Retrouvez instantanément chaque fonctionnalité ou correctif par type et périmètre.
semantic-release analyse les Conventional Commits pour générer des journaux des modifications et incrémenter automatiquement les numéros de version.
Les personnes qui relisent le code comprennent l'intention avant même d'ouvrir un fichier. Un message de commit clair réduit considérablement le temps de revue.
Objets de moins de 72 caractères, à l’impératif, avec une ligne vide avant chaque paragraphe du corps du message.
Coller git diff --staged et l’IA analyse vos modifications réelles pour produire le message le plus précis possible.
Les formats de commit de style GitHub, de style Angular et liés à Jira sont tous disponibles - indiquez simplement votre préférence.
Référence des types Conventional Commits
Le préfixe de type est l’élément sur lequel les développeurs hésitent le plus. Ce tableau présente les dix types standard et les cas où chacun s’applique.
| Type | Quand l’utiliser |
|---|---|
feat | Une nouvelle fonctionnalité que les utilisateurs peuvent voir ou appeler. Déclenche une augmentation de version mineure dans semantic-release. |
fix | Une correction de bug qui rectifie un comportement erroné. Déclenche une incrémentation du numéro de correctif. |
docs | Documentation uniquement : README, commentaires du code, documentation API. Aucun code de production modifié. |
style | Mise en forme, espaces, points-virgules, corrections de lint. Le sens du code reste inchangé. |
refactor | Restructuration du code qui ne corrige aucun bug et n'ajoute aucune fonctionnalité, comme l'extraction d'une fonction. |
perf | Une modification visant à rendre le code plus rapide ou plus léger, comme l'ajout d'un cache. |
test | Ajout ou correction de tests. Le code de production reste inchangé. |
build | Système de compilation ou dépendances externes : paquets npm, configuration webpack, Dockerfiles. |
ci | Configuration du pipeline CI : workflows GitHub Actions, fichiers Jenkins, scripts de déploiement. |
chore | Maintenance qui ne relève d’aucune autre catégorie : mise à jour des versions, modification de .gitignore. |
Portées et modifications incompatibles
Un scope précise le type en indiquant la zone du code concernée : feat(auth): add OAuth login ou fix(parser): handle empty input. Pour signaler un changement incompatible, ajoutez ! après le type ou la portée, comme dans feat(api)!: remove legacy v1 endpoints, et ajoutez un BREAKING CHANGE: pied de message décrivant la migration. Des outils comme semantic-release lisent ce marqueur et publient une version majeure.
Du mauvais au bon : trois réécritures de messages de commit
Le moyen le plus rapide d’assimiler le format est de voir comment corriger des messages faibles. Chaque réécriture ci-dessous ajoute un type, passe à l’impératif et explique pourquoi, pas seulement quoi.
Avant : updated stuff
Après : fix(checkout): prevent double-submit on slow connections
Le texte d’origine n’apprend rien à la personne qui le lira plus tard. La reformulation précise la zone concernée, le comportement et la condition qui l’a déclenché.
Avant : added some tests and fixed the date bug
Après : fix(reports): use UTC when grouping orders by day ainsi qu’un élément distinct test(reports): cover month-boundary grouping
Deux modifications sans rapport doivent faire l’objet de deux commits, chacun formulé à l’impératif.
Avant : change timeout from 30 to 5
Après : perf(api): lower upstream timeout to 5s avec cette phrase dans le corps du texte : "Des délais d'expiration de 30s permettent à un seul fournisseur lent de saturer le pool de processus de traitement pendant les pics de trafic."
Le diff montre déjà que le nombre a changé. Le message conserve le raisonnement.