TECHNOLOGIES
Git, notre gestionnaire de versions
Git est le fondement de notre workflow de développement. Il assure la traçabilité de chaque modification, permet le travail en équipe sans friction et constitue le point d'entrée de notre chaîne CI/CD GitLab.
Cette fiche documente nos conventions de commits, notre stratégie de branches et nos bonnes pratiques de versionning.
POURQUOI GIT
Ce qui en fait le socle de notre développement
Git est présent sur tous nos projets sans exception. Voici les six raisons pour lesquelles nous ne pourrions pas travailler sans lui.
Historique complet et traçabilité
Chaque modification est enregistrée avec son auteur, sa date et son contexte. On peut retrouver à tout moment pourquoi une ligne a été écrite, qui l'a modifiée et dans quel cadre — même des années après.
Travail en parallèle sans conflit
Les branches permettent à plusieurs développeurs de travailler simultanément sur des fonctionnalités différentes sans se bloquer mutuellement. Git gère la fusion et signale les vrais conflits.
Retour arrière fiable
Chaque commit est un point de restauration. En cas de régression ou de mauvaise direction, on peut revenir à n'importe quel état antérieur du code en quelques secondes sans perdre le travail réalisé en parallèle.
Revue de code sur les diffs
Git produit des diffs précis qui montrent exactement ce qui a changé entre deux états. La revue de code dans GitLab s'appuie sur ces diffs pour cibler les commentaires ligne par ligne.
Versioning des releases
Les tags Git marquent les versions livrées en production. Associés aux releases Sentry, ils permettent de corréler une erreur à un commit précis et d'identifier la régression introduite.
Socle de la CI/CD
Chaque push déclenche le pipeline GitLab CI. Git est le point d'entrée de toute notre chaîne d'automatisation : tests, analyse statique, build et déploiement sont tous pilotés par les événements Git.
NOTRE USAGE
Comment nous utilisons Git chez SmartBooster
Nos conventions Git garantissent un historique lisible et un workflow fluide quelle que soit la taille de l'équipe.
Messages de commit conventionnels
Nos commits suivent un format structuré : type(scope): description. Cela facilite la lecture de l'historique, la génération de changelogs et la compréhension du contexte de chaque changement.
Branches courtes et ciblées
Une branche = une fonctionnalité ou un correctif. Les branches feature/ et fix/ sont mergées rapidement pour limiter les conflits et garder un historique lisible.
Rebase avant merge
On rebase la branche sur main avant de créer la MR. L'historique reste linéaire, les conflits sont résolus tôt et le pipeline tourne sur un code à jour.