Les meilleures façons de rédiger des messages de commit Git : comme les pros

Lorsqu'un développeur remonte dans le temps pour chercher quelque chose sur lequel il a travaillé six mois auparavant, il ne comprend souvent pas pourquoi il a fait ce commit particulier, et la seule raison en est qu'il n'a pas suivi la bonne façon d'écrire le message de commit.

\ Il existe des normes de messages de commit que les développeurs pratiquent dans le monde entier, et il est bon de suivre les normes populaires afin que lorsque vous revenez après un bon laps de temps ou que quelqu'un d'autre regarde vos messages de commit, ils ne paraissent pas embarrassants !

\

\ Les équipes devraient d'abord décider d'une convention de message de commit qui spécifie l'historique du contrôle de version du produit qu'elles construisent.

\ Un bon message de commit Git doit avoir un style approprié, un contenu et des métadonnées.

\ Un commit Git connu suit cette convention :

<type>(<scope>): <message>

\ <type> peut être l'un des suivants :

• feat pour une nouvelle fonctionnalité.
• refactor pour la refactorisation du code de production, par exemple, le renommage d'une fonction.
• docs pour les modifications apportées à la documentation.
• fix pour une correction de bug pour l'utilisateur.
• perf pour les améliorations de performance.
• style pour les changements de formatage, les points-virgules manquants, etc.
• test pour ajouter des tests manquants, refactoriser des tests.
• build pour la mise à jour de la configuration de build, des outils de développement ou d'autres modifications non pertinentes pour l'utilisateur.

\ Vous pouvez également ajouter votre propre type personnalisé, en fonction des normes suivies par votre équipe. Les normes ci-dessus sont suivies par l'équipe ESLint. Vous pouvez consulter leurs messages de commit ici.

\ La portée est facultative, et la partie message doit inclure une déclaration d'une seule ligne, pas plus de 72 caractères, pour résumer l'objet du commit.

\ De nombreux développeurs utilisent également le message comme ligne d'objet et ajoutent aussi un corps ; c'est essentiellement la description du commit, mais un message de commit d'une seule ligne est préférable tant que vous pouvez comprendre le contexte (le quoi et le pourquoi du commit). Si le commit nécessite une description plus détaillée qui ne peut pas être expliquée en une seule ligne, un corps de commit est toujours nécessaire.

\ Vous pouvez également utiliser des outils comme Glitter ou Commitizen pour standardiser vos messages de commit.

\ Non seulement cela, mais vous pourriez aussi vous demander s'il existe un outil qui vérifie votre message de commit et affiche une erreur s'il ne suit pas les directives. Commit lint en est un. Il aide votre équipe à adhérer à une convention de commit.

\ Souvent, les experts de l'industrie utilisent leur ticket JIRA ou Click Up comme message de commit afin que tout puisse être lié ou retracé à tout moment, et que la base de code reste maintenable pour les futurs développeurs.

\ Certaines équipes aiment également ajouter des émojis à leurs messages de commit. J'ai organisé une liste d'émojis et leurs significations respectives. Vous pouvez la consulter ici.

\ En fin de compte, l'important est que votre message de commit soit significatif et ne confonde pas vos collègues développeurs ou les futurs développeurs sur la nature d'un changement particulier.

\ Si vous souhaitez en savoir plus sur les commits conventionnels, les commits sémantiques ou les pratiques suivies par l'industrie, voici quelques ressources pour vous :

1. Commits Conventionnels
2. Commits Sémantiques
3. Comment écrire un message de commit par CBeams

\