Comment nommer ses branches et ses commits sur Git ?

Lorsque l'on utilise Git pour versionner son code et que l'on n'impose pas une convention de nommage généralisée, on perd très vite l'intérêt même d'utiliser un gestionnaire de versions.

Car après tout, comment retrouver facilement l'endroit où une erreur a été introduite quand la moitié des messages de commit ressemblent à "fix", "another fix", "i'm tired", ou "fuck this" ?

Depuis plusieurs années, j'ai créé une convention de nommage pour les branches ainsi que les messages de commit inspirée de ce que j'ai pu rencontrer dans certaines équipes.

Les branches

Je distingues trois types de branches sur un projet : Les branches globales, les branches personnelles et les branches de tâches.

Branches globales

Une branche globale est une branche qui n'est gérée que par un nombre très restreint de développeurs et qui a des conséquences sur les déploiements. On ne doit jamais coder directement dans ces branches, tout le code doit provenir de merge-requests qui auront subit une code-review au préalable.

Ces branches s'appellent en général : master, preprod, dev, ...

Les branches personnelles

Ces branches sont les branches principales sur lesquelles les développeurs travaillent en autonomie sur leur sprint respectif pour la version de dev actuelle.

Ces branches sont donc toutes nommées : dev/[prénom], dev/[initiales] ou encore dev/[prénom nom].

Les branches de tâches

Il arrive parfois qu'un ou plusieurs devs doivent travailler sur une tâche qui sort de leur workflow actuel, disons une correction de bug sur la version actuelle, alors que leur sprint porte sur la prochaine version de l'application.

Alors on créé une branche spécifique à cette tâche, basée sur la branche globale désirée, en prenant soin de préfixer le nom de la branche par le type de tâche à effectuer, exemples :

• fix/user-signup
• doc/missing-route
• ux/onboarding-improvement

Attention, pour garder un dépôt propre, l'idéal est de supprimer chaque branche de tâche une fois que cette dernière a été fusionnée avec une branche globale.

Les commits

Pour les commits, comme ces derniers peuvent contenir un maximum d'infos importantes, j'ai essayé de trouver une forme qui serait à la fois agréable à l'oeil, pas trop difficile à écrire et qui hiérarchise bien les informations.

J'en suis arrivé à la forme suivante :
[type] module (issue) - message

Dans lequel "type" correspond au type de la tâche (feature, fix, doc, refactor,...), "module" correspond à la partie de l'application qui sera affectée (User, Account, Post,...), "issue" correspond numéro de l'issue Git qui sera résolue "message" correspond à la description textuelle de la tâche effectuée.

Ce qui donne des messages de commit ressemblant à ceci :

• [REFACTOR] User (#5) - Merging User and Account models
• [FIX] Notifications (#18) - Emails were not sending due to wrong smtp credentials
• [FEATURE] Post (#65) - Images can be added to posts using the editor

Libre à vous d'adapter cette convention selon vos besoins, mais cela fait plusieurs années que je l'utilise et je la trouve toujours aussi pertinente.