Convention de message de commit

The contens of this page are partly based on the angular commit messages document.

Objectif

Le message de commit est ce qui décrit votre contribution. C’est pourquoi le but est de décrire ce que le commit apporte au projet;

L’entête doit être aussi explicite que possible car elle est toujours lu avec les autres message de commit.

Le corps doit fournir les informations nécessaires pour ceux qui souhaitent comprendre le commit.

Le pied peut contenir des références à des documents externes (incidents résolut, …) aussi bien que des notes sur les changements structurels.

Cela s’applique à tout les type de projet.

Format

Forme courte (uniquement la ligne de sujet)

<type>(<scope>): <subject>

Forme longue (avec le corps)

<type>(<scope>): <subject>

<BLANK LINE>

<body>

<BLANK LINE>

<footer>

La première ligne de doit pas dépasser les 70 caractères. La ligne suivante est toujours une ligne blanche et les lignes suivante doivent se limiter à 80 caractères! Cela rend le message plus facile à lire sur github comme sur la plus part des autres outils git.

Ligne de sujet

Le sujet contient une description succincte des changements.

`<type>` autorisé

feat (fonctionnalité)
fix (correction de bug)
docs (documentation)
style (formatage, oublie divers, …)
refactor
test (lors d’ajout de test manquant)
chore (maintenance)
improve (amélioration)

`<scope>` autorisé

Le scope peut spécifier l’emplacement des changements du commit. Par exemple dans le camunda-modeler project cela peut être “import”, “export”, “label”, …

Texte du `<subject>`

Utiliser l’impératif présent: change et pas changed ou changes ou changing
Ne pas mettre la première lettre en majuscule
ne pas mettre de ’.’ à la fin

Corps du message

Comme pour le sujet, utiliser l’impératif présent
Ajoutez les motivations du changement et comparez avec la version précédente

Pied du message

Changements “cassant”

Tous les changement cassants doivent être mentionné dans le pied avec la description du changement, la justification et la procédure de migration.

BREAKING CHANGE: Id editing feature temporarily removed

As a work around, change the id in XML using replace all or friends

Incidents référencés

Bug fermé / feature requests / problèmes doivent être listé sur une ligne séparé dans le pied préfixé du mot clé “Closes” comme :

Closes #234

or in case of multiple issues:

Closes #123, #245, #992

Plus sur les bonnes pratiques de commit

FAQ pour les Geeks

Pourquoi utiliser l’impératif présent dans les messages ?
Faire de log de commit plus lisible. Voyez le travail que vous faite pendant le commit comme un travail sur le un problème dont le commit en est la solution. Maintenant comment le commit est une solution au problème.

Exemple: Vous écrivez un test pour la fonction #foo. Vous commitez le test. Vous utilisez le message de commit add test for #foo. Pourquoi ? Car c’est ce que le commit résout.

Comment caractériser les commit qui résultent directement d’un merge ?
Utilisez chore(merge): <what>.

Je veux commiter un micro-changement, que dois je faire ?
Demandez vous pourquoi c’est un micro-changement. Utilisez feat = docs, style or chore selon le changement. SVP regarder la prochaine question si vous commiter un travail en cours.

Je veux committer un travail en cours. Que dois je faire?
Ne le faite pas ou faite le sur une branche non publique (pas sur develop ni sur master).

Quand vous avez finir le travail committer avec un message cohérent et poussez sur la branche publique.