Clean Git : Convention de nommage et maîtrise de l'historique

Dans un environnement professionnel, Git n'est pas seulement un outil de sauvegarde, c'est le journal de bord de votre projet. Un historique propre et des branches bien nommées sont les fondations d'une revue de code efficace et d'un déploiement serein.

1. Stratégie de nommage des branches

Le nom d'une branche doit permettre à n'importe quel membre de l'équipe d'identifier le type de travail et le ticket associé sans ouvrir Jira ou Redmine.

Conventions recommandées (Prefix/ID-Description)

feature/ : Développement d'une nouvelle fonctionnalité (ex: feature/123-api-auth).
fix/ : Correction d'un bug identifié (ex: fix/456-cart-total-tax).
hotfix/ : Correction urgente en production (ex: hotfix/789-security-patch).
refactor/ : Amélioration du code sans changement fonctionnel.

2. Un historique propre : Rebase vs Merge

Pour un Lead Développeur, la clarté de l'historique est primordiale. Deux philosophies s'affrontent :

Le Rebase (Conseillé) : En utilisant git rebase main sur votre branche de feature, vous réécrivez vos commits par-dessus le dernier commit de la branche principale. Cela crée un historique linéaire, facile à lire et à déboguer.
Le Merge : Crée un "commit de fusion" qui mélange les timelines. À éviter sur les branches de fonctionnalités pour ne pas polluer l'historique avec des messages "Merge branch...".

3. L'art du commit atomique

Un bon commit doit répondre à une seule intention. Si vous corrigez un bug ET que vous reformatez le code, faites deux commits.

Structure d'un message professionnel

[#ID_TICKET] type(scope): subject

- Description détaillée des changements
- Pourquoi ce changement était nécessaire

4. Techniques avancées : Squash et Tags

Avant de fusionner une Pull Request, utilisez le Interactive Rebase (git rebase -i) pour "squasher" (fusionner) vos petits commits de travail (ex: "fix typo", "wip") en un seul commit propre et significatif.

Enfin, utilisez les Tags pour marquer vos déploiements (ex: v1.2.0). Cela permet un retour arrière (rollback) rapide et une traçabilité parfaite des versions mises en production.

En adoptant ces standards, vous réduisez la charge cognitive de l'équipe lors des revues de code et facilitez grandement l'intégration continue.

Sabrine FERCHICHI

Lead développeuse experte Sylius et certifiée Scrum Developer Agile. Spécialisée dans la conception d'architectures e-commerce robustes, je partage ici ma veille technologique et mes retours d'expérience axés prioritairement sur l'écosystème Sylius et Symfony.