Le but des messages de commit est de décrire les changements que ce “commit set” effectue. L'idée est que lorsque l'on relira par la suite le message de commit, l'on puisse comprendre les changements que ce commit met en oeuvre.

Best Practices

• La première ligne doit être un court résumé d'une seul ligne (moins de 50 caractères)
• éventuellement suivie par une ligne blanche ou une description plus complète.
• garder les lignes en dessous de 72 caractères (pour lecture dans terminal, applications ou au-dessus cela peut gêner).
• écrire au présent, et à la troisième personne : on décrit ce que fait le commit set, pas ce qu'on a fait nous
• possibilité d'ajouter des références à des “tickets”
• can develop shorthands (abbréviations ?) for your organisation (dans le sens organiser)
  • ex : “[css/js]”, “bugfix:”, “#10256”
• être clair et descriptif
  • ex: pas bien : “update login code” / bien : “change user authentification to use blowfish”
  • ex: pas bien : “fix type” / bien : “add missing > in project section of HTML”

Ces messages vont rester des années, ce n'est pas une communication instantannée, ils doivent pouvoir être relu et compris bien après, ou par quelqu'un d'extérieur.