Les commits conventionnels ne sauveront pas vos messages de commit

Une recherche rapide sur internet révélera une pléthore d'articles vous enseignant comment écrire des messages de commit. 90 % de ces articles vous disent d'utiliser les commits conventionnels. Cependant, un nombre considérable de développeurs ont encore du mal avec cela. Ils savent qu'ils devraient suivre ces conventions, mais ils trouvent difficile de les appliquer en pratique. Chaque fois qu'ils committent du code, ils se demandent s'ils doivent écrire "refactor" ou "chore". J'ai même vu des projets où la liste des messages de commit se compose entièrement du même message : "feat : ajouter page", car écrire des messages de commit était trop difficile pour eux, et ils ont tout simplement abandonné.

Il est trop tôt pour parler des commits conventionnels#

Je ne dis pas que les commits conventionnels sont mauvais. Ils ont de nombreux avantages bien connus :

• Ils fournissent un format unifié, rendant les messages de commit plus standardisés
• Ils sont faciles à analyser pour les outils automatisés, permettant la génération automatique de journaux de changements
• Ils aident les membres de l'équipe à comprendre le but et la portée des changements de code
• Ils permettent d'identifier rapidement les différents types de changements de code

Cependant, quand un développeur a encore du mal à écrire de bons messages de commit même après avoir utilisé les commits conventionnels, lui donner un article sur comment utiliser les commits conventionnels, lui enseigner ce que signifie le type feat, ce que signifie le type fix, est en réalité inutile. C'est comme donner un livre de cuisine avancé à quelqu'un qui ne sait pas cuisiner, sans lui apprendre à utiliser les ingrédients de base et les ustensiles. Pourtant, de tels articles sont omniprésents sur internet. Peu savent que les commits conventionnels ne peuvent être réellement efficaces que lorsque les développeurs ont une réflexion claire et la capacité de diviser précisément les tâches.

Donc, les commits conventionnels ne sont pas mauvais, mais avant d'y arriver, nous devons établir le bon état d'esprit de développement et utiliser une réflexion scientifique de développeur pour faire les choses.

Réflexion clé pour écrire de bons messages de commit#

Les changements de code doivent faire une chose à la fois#

Dans le développement logiciel, "faire une chose à la fois" est un principe important. Cela s'applique non seulement à l'écriture du code, mais aussi aux commits de code. Lorsque nous nous concentrons sur une tâche ou un changement spécifique à la fois, notre code devient plus clair et nos intentions plus explicites. Cette méthode améliore non seulement la lisibilité du code, mais simplifie également grandement le processus de révision du code. Les réviseurs peuvent plus facilement comprendre et vérifier le but de chaque changement.

De plus, cette méthodologie offre une commodité pour les retours arrière potentiels du code. Si des problèmes surviennent, nous pouvons plus facilement localiser et annuler des changements spécifiques sans affecter d'autres parties non liées. Plus important encore, lorsque chaque changement fait une seule chose, le message de commit décrivant ce changement devient naturellement plus précis et significatif.

En pratique, cela signifie que nous devons définir clairement la tâche à accomplir avant de commencer à coder. Après avoir terminé une tâche, nous devrions immédiatement committer le code, plutôt que d'attendre que plusieurs tâches soient terminées avant de committer ensemble. Si nous découvrons d'autres domaines nécessitant des modifications lors de la réalisation de la tâche actuelle, la meilleure approche est de les noter et de les traiter séparément après avoir terminé la tâche actuelle. Par exemple, lorsque tu implémente une fonctionnalité et découvre quelques bugs existants, ce que tu devrais faire n'est pas de corriger le bug immédiatement avec ton nouveau code de fonctionnalité, mais plutôt d'implémenter la fonctionnalité d'abord, puis de corriger le bug que tu as découvert dans un autre commit, ou de corriger le bug en premier puis de committer la fonctionnalité.

Les messages de commit existent en réalité avant d'écrire le code#

De nombreux développeurs ne commencent à penser à comment écrire les messages de commit qu'après avoir terminé le code, mais en réalité, les messages de commit devraient exister avant que nous commencions à coder. C'est parce que les messages de commit reflètent essentiellement les étapes que nous prenons pour accomplir une tâche. En d'autres termes, ce sont nos éléments à faire.

Lorsque nous commençons une tâche, nous devrions d'abord réfléchir aux étapes spécifiques nécessaires pour accomplir cette tâche. Ces étapes sont notre liste de choses à faire, et en même temps, elles sont nos futurs messages de commit. Avec cette liste de choses à faire, chacun de nos changements de code a un but, nous gardant concentrés pendant que nous codons et nous empêchant de dévier de la tâche.

Plus important encore, cette méthode peut améliorer considérablement notre efficacité. Lorsque nous terminons une étape, le message de commit correspondant est déjà préparé, et nous pouvons l'utiliser directement, réduisant ainsi le temps passé à réfléchir à comment décrire le changement. En même temps, parce que ces messages de commit sont complétés lorsque nous avons une compréhension complète de la tâche, ils sont généralement de meilleure qualité et plus informatifs.

Supposons que tu doives implémenter une nouvelle fonctionnalité d'inscription utilisateur. Tu pourrais planifier les étapes de ta tâche comme suit :

1. Réorganiser le composant de formulaire existant pour le rendre plus générique et réutilisable
2. Créer un formulaire d'inscription utilisateur
3. Mettre en œuvre l'intégration API pour l'inscription utilisateur
4. Ajouter des tests unitaires pour la fonctionnalité d'inscription utilisateur
5. Mettre à jour la documentation pour la fonctionnalité d'inscription utilisateur

Les messages de commit correspondant à ces étapes de tâche pourraient être les suivants :

1. refactor : améliorer le composant de formulaire existant pour la réutilisabilité
2. feat : créer un formulaire d'inscription utilisateur
3. feat : mettre en œuvre l'intégration API pour l'inscription utilisateur
4. test : ajouter des tests unitaires pour l'inscription utilisateur
5. docs : mettre à jour la documentation pour la fonctionnalité d'inscription utilisateur

De cette façon, tu as des étapes de tâche claires et des messages de commit concis correspondants avant de commencer à coder. Ces messages de commit sont en réalité ta liste de choses à faire, te guidant tout au long du processus d'implémentation de la fonctionnalité.

Lorsque tu termines chaque étape, tu peux utiliser le message de commit correspondant pour committer ton code. Cela t'aide non seulement à mieux organiser et exécuter les tâches, mais garantit également que chaque commit se concentre sur une étape spécifique, rendant l'ensemble du processus de développement plus clair et gérable. Si tu as besoin d'ajuster légèrement le message de commit pendant le codage réel, tu peux apporter de petites modifications pour décrire plus précisément les changements réels.

Les commits conventionnels deviennent un choix naturel#

Quand nous développons le bon état d'esprit de développement, l'utilisation des commits conventionnels devient naturelle. À ce stade, tu trouveras que choisir le préfixe de type approprié (comme feat, fix, refactor, etc.) devient sans effort car tes messages de commit reflètent déjà clairement tes étapes de tâche.

Si tu veux en savoir plus sur l'utilisation des commits conventionnels, il y a de nombreux excellents articles disponibles en ligne. Mais souviens-toi, ces normes ne peuvent être réellement efficaces que lorsqu'elles reposent sur le bon état d'esprit de développement.

Conclusion#

Écrire de bons messages de commit ne consiste pas seulement à suivre un certain format. Cela nous oblige à maintenir une réflexion claire pendant le processus de développement, clarifier le but de chaque changement, et à réfléchir à comment décrire notre travail avant de commencer à coder.

Les commits conventionnels sont en effet un outil utile, mais ils ne peuvent exercer leur effet maximal que lorsqu'ils sont combinés avec le bon état d'esprit de développement. En pratiquant les deux principes "faire une chose à la fois" et "réfléchir aux messages de commit à l'avance", nous pouvons non seulement améliorer la qualité des messages de commit mais aussi renforcer l'efficacité globale du développement et la qualité du code.

J'espère que cet article t'aide à repenser ton processus de développement et t'encourage à essayer ces méthodes. Souviens-toi, de bonnes habitudes de développement prennent du temps à se cultiver, mais une fois formées, elles amélioreront grandement ton efficacité de travail et la qualité du code.