Git & Version Control
Composez des champs ou vérifiez un message complet. Chaque mode conserve son propre brouillon.
Les types proposés sont courants. Vous pouvez saisir votre propre type.
Commencez par Refs: #42 ou Closes #42. Les lignes ordinaires suivantes prolongent la valeur précédente.
Les messages restent dans ce navigateur, sans accès au dépôt ni envoi réseau.
Structure Conventional Commits 1.0.0 ; sans règles du projet ni limite de 50/72 caractères. Maximum : 20 000 unités UTF-16.
Saisissez une description ou un message complet.
Le Générateur de messages de commit sert lorsque le changement est clair, mais que sa description risque de mélanger titre, contexte et indications de compatibilité. Les Commits Conventionnels attribuent un rôle précis à ces éléments. Le formulaire et le texte à vérifier restent deux brouillons distincts : vous pouvez consulter un message existant sans effacer les champs déjà saisis. Le résultat expose la déclaration écrite, sans examiner le code.
Le Générateur de messages de commit assemble le type, l’étendue facultative et la description sur la première ligne. Il ajoute une ligne vide entre les sections et préserve les paragraphes internes. Cette séparation permet de relire le message de commit avant de le coller ailleurs, sans remplacer un type personnalisé ni modifier automatiquement sa casse.
Une déclaration feat correspond normalement à une évolution mineure. Un ! avant les deux-points ou un pied de rupture valide déclare une évolution majeure, quel que soit le type. La synthèse montre cette priorité pour attirer l’attention sur le sens du texte. Elle ne prouve pas que le code introduit réellement une rupture de compatibilité.
La liste ne contient que des suggestions usuelles. Vous pouvez saisir un autre nom choisi par votre équipe. Le vérificateur ne lit pas les différences du code : il ne peut donc pas confirmer qu’une correction annoncée résout un bug ou qu’un changement est une fonctionnalité.
Un pied peut commencer par Refs: #42 ou Closes #42. Les lignes ordinaires qui suivent prolongent sa valeur ; un nouveau couple jeton-séparateur ouvre une autre entrée. Utilisez le champ dédié pour rendre votre intention explicite et vérifiez où le corps du message se termine.
Le traitement automatique attend 350 ms après la dernière modification. Désactivez-le pour utiliser le bouton ou Ctrl/Cmd + Entrée. Toute modification du texte, d’un champ ou de ! bloque aussitôt la copie et le téléchargement, jusqu’au prochain traitement de cette entrée précise.
La première ligne contient un type, une étendue éventuelle et un résumé. Corps et pieds peuvent comporter plusieurs lignes. La casse est conservée, mais FEAT et feat ont le même sens pour la version déclarée. Le résumé peut être en français ; dépasser 50 ou 72 caractères ne constitue pas ici une erreur de syntaxe.
Le mode de validation contrôle l’en-tête, la séparation obligatoire et les pieds reconnaissables. Les erreurs restent visibles avec leur ligne et leur colonne, et l’éditeur souligne la ligne concernée. Une URL ou des deux-points dans une phrase du corps ne rendent pas automatiquement le message invalide. Le formulaire conserve son propre contenu.
Placez ! après le type ou l’étendue, juste avant les deux-points. Avec ce signe, un pied supplémentaire n’est pas obligatoire. Vous pouvez aussi écrire BREAKING CHANGE: suivi d’une explication ; BREAKING-CHANGE: est équivalent. Ces jetons particuliers exigent les majuscules. La copie et le fichier ne contiennent que le texte du message.
Les deux casses sont acceptées. La spécification demande de ne pas distinguer majuscules et minuscules pour interpréter les types. Conservez une convention cohérente dans votre équipe. Le vérificateur préserve votre saisie, mais les jetons BREAKING CHANGE et BREAKING-CHANGE constituent des exceptions : ils doivent être en majuscules.
Si possible, séparez les modifications ayant des objectifs différents en plusieurs commits. Ici, un message ne possède qu’un seul type. Le corps peut apporter du contexte, mais le choix de feat ne confirme pas que toutes les modifications sont correctement classées. Vérifiez séparément leur effet sur la compatibilité.
fix déclare un correctif, feat une évolution mineure et ! ou un pied de rupture valide une évolution majeure. La rupture est prioritaire sur le type. Cette page montre seulement cette intention : elle ne connaît ni votre version actuelle, ni les préversions, ni les règles de votre chaîne de publication.
Si le message est encore un brouillon, corrigez le type et relancez la vérification. Une faute comme feet peut être structurellement valide puisque les types personnalisés sont permis. Modifier un commit déjà créé relève du dépôt ; la page ne réalise ni amend ni rebase et ne modifie pas votre historique.
La spécification laisse le traitement des annulations aux auteurs des outils. Un type revert et un pied Refs peuvent désigner les commits concernés. Le vérificateur accepte cette structure, mais ne soustrait pas les effets des changements précédents et ne détermine pas la version à publier après leur annulation.
Un format à examiner ?
Revenez au Générateur de messages de commit, confrontez la déclaration au changement réel, puis exportez le résultat à jour après sa vérification structurelle.