L'agence
WanadevStudio
Retour d'expérience : notre utilisation de Git sur un gros projet
Git, l'incontournable outil de versioning : nous l'utilisons sur chacun de nos projets. Manier Git au sein d'une équipe complète demande rigueur et discipline. Dans cet article, nous allons détailler comment nous nous organisons sur un gros projet à fortes contraintes techniques.
L'obligation de structurer son workflow avec Git
Quand nous travaillons seuls, nous sommes souvent tentés de se laisser aller : ne travailler que sur la branche Master, faire 3 commits par semaine et pusher tous les 4 matins.
En équipe, cette mauvaise habitude vous fera vous arracher les cheveux (ou ceux de vos coéquipiers) sous le poids des conflits permanents qui vont tomberont sur le bec. Vous pouvez me croire : je suis bientôt chauve.
Les conflits sont le désagrément le plus criant, mais pas le plus problématique : le manque de traçabilité du à une mauvaise organisation d'un workflow Git sera douloureux à un moment donné.
@ L'intérêt principal de Git, c'est le versioning : pouvoir remonter le temps, étape par étape, commit par commit, pour revenir à des versions antérieures, et surtout stables.
Comment imaginez-vous pouvoir assurer des rollbacks sécurisés sans rigueur dans votre organisation ? Regardons ensemble ce que nous avons instauré sur nos projets.
Cas concret de workflow Git : l'équipe Kozikaza.com
^ Cet exemple relate notre expérience et notre fonctionnement, mais il est certain qu'il existe de nombreuses autres excellentes façon d'organiser un workflow Git. Chaque équipe, chaque projet, chaque environnement définit son propre corpus d'éléments amenant à de nombreuses autres judicieuses organisations.
Chez Wanadev, un groupe technique composé de 4 à 6 personnes (en fonction de la charge ou de la nature des travaux) se concentre sur les développements et évolutions de la plateforme dédiée à la maison. Une seconde équipe de taille similaire basée à Lille s'occupe de la gestion de la communauté, et l'organisation générale de la plateforme.
Au fil des années et des nouveautés, nous avons, entre autres grâce à la méthode KaiZen, en permanence remis en question nos fonctionnements pour toujours améliorer nos méthodes de travail... dont notre workflow Git.
@ Pour cette plateforme à fort trafic, il est impératif que toutes les personnes qui œuvrent à son bon fonctionnement travaillent de façon organisée.
Notre organisation Git
Branche Master : c'est notre branche la plus basse, la plus stable. C'est aussi celle qui est câblée en production. Personne ne peut pusher dessus, elle est protégée, seule une procédure de mise en production permet une mise à jour de la branche.
Branche Develop : c'est la branche la plus stable après Master. Elle est mise à jour lorsque les développements sont terminés, c'est notre branche de tests finaux, celle qui est notre témoin, notre répétition générale. Cette branche est câblée sur notre preproduction.
Branche v5rX/develop : V5, pour la 5e version de la plateforme, X étant le numero de la release sur laquelle nous travaillons. En ce moment, nous en sommes à la v5r20/develop. Cette branche est celle correspondant aux travaux en cours. Notre serveur de dev est câblé sur cette branche pour valider les sprints et développements en cours.
Enfin, la branche v5rX/Y correspond à une feature développée en ce moment. Par exemple : v5r20/preview_notif. Cette branche est accessible en local, elle est très rarement mise à disposition d'un serveur de preproduction.
Les hotfix
Parfois, malgré tous nos efforts, des petites coquilles restent et il faut patcher la prod. Evidemment, ce cas doit se présenter le moins souvent possible, mais quand il faut... il faut !
Une fois le fix développé, testé et retesté (sur la branche develop), la procédure de hot fix peut être lancée. Nous mergons ainsi la branche Develop sur la branche Master (puisque Develop est saine).
Un workflow n'est jamais parfait et il est toujours améliorable
C'est aujourd'hui ce workflow qui convient à nos sprints de développements. Il sera sans doute modifié dans la continuité du projet, pour qu'il soit toujours en adéquation avec les demandes et équipes en place.
Vous êtes invités à réagir à cette organisation en nous interpellant en commentaire ou bien sur Twitter : vos réactions nous intéressent et elles feront sans aucun doute évoluer nos façons de travailler ;-) !
Sources et compléments
-
Retour sur le Meet-up Python du 30 juin 2025Il y a 2 mois
Ce lundi 30 juin 2025 nous accueillions la branche lyonnaise de l'AFPy dans nos locaux pour un meetup autour du langage Python. Malgré les fortes températures, une trentaine de personnes ont répondu présentes pour ce moment de convivialité et d'échange.
-
Figma Make : enfin une passerelle prometteuse entre design et code grâce à l'IAIl y a 2 mois
Depuis quelques années, les outils d'IA pour générer des intégrations d'interfaces à partir de maquettes fleurissent. On en a testé plusieurs chez WanadevDigital : de Locofy à Uizard, en passant par Framer AI. Tous ont leurs qualités, mais jusqu’ici, il manquait un vrai pont stable entre les intentions du designer et la réalité du code front.
L’arrivée de Figma Make change la donne. Et si je devais résumer son impact en une phrase : ça fonctionne, et ça fonctionne pour tout le monde, designers, développeurs et intégrateurs !
-
Maîtriser la traduction (i18n) dans un projet web - Partie 2 : Conseils pour une localisation gérable et évolutiveIl y a 5 mois
Dans la partie 1, nous nous sommes concentrés sur la mise en place d'une base solide pour la gestion des traductions dans un projet Vue. Maintenant que votre système de traduction est opérationnel, il est temps d'examiner de plus près comment structurer, gérer et faire évoluer vos fichiers de traduction de manière efficace.
Cette partie couvrira les bonnes pratiques que nous utilisons chez Wanadev pour créer des clés de traduction maintenables, éviter les pièges courants et garantir que vos fichiers de traduction restent propres et évolutifs au fur et à mesure que votre projet grandit.
-
Maîtriser la traduction (i18n) dans un projet web - Partie 1 : Configurer proprementIl y a 5 mois
Mettre en place l'internationalisation (i18n) dans un projet web peut sembler simple. Cependant, de nombreux projets se retrouvent avec des configurations de traduction mal gérées, difficiles à maintenir ou à faire évoluer à mesure que l'application grandit. Une stratégie i18n robuste est essentielle pour offrir une expérience utilisateur fluide dans plusieurs langues.
Je vous décris ici, les pratiques que nous avons établies chez Wanadev au fil des années d'expérience pour mettre en œuvre et gérer les traductions dans les projets Vue. Bien que les exemples soient spécifiques à Vue, la plupart de ces pratiques peuvent être appliquées à n'importe quel framework.
-
Bien choisir sa typographie : quelques bases pour un message clairMéthodologieIl y a 10 mois
On n'écrit pas "Je t'aime" comme "Je te hais" ! Cette petite phrase résume bien ma problématique : quand on doit délivrer un message, la compréhension de ce dernier ne se fait pas uniquement par la lecture simple du texte, mais aussi par sa mise en forme. Et de cette mise en forme dépend la bonne compréhension du message. Dans cet article, nous allons nous pencher sur l’histoire et les familles de typographies dans le but de sensibiliser sur l’importance des choix de typographies dans la communication. Nous verrons ensuite quelques astuces pour bien sélectionner sa typographie et mettre en forme son message.
-
Les solutions CPQ sont-elles accessibles à toutes les entreprises ?MéthodologieIl y a 11 mois
Le CPQ (Configure, Price, Quote) est un outil essentiel pour les entreprises cherchant à optimiser leurs processus de vente. Il permet aux équipes commerciales de configurer rapidement et facilement des produits ou services complexes en fonction des besoins spécifiques des clients, tout en garantissant la cohérence des prix. Grâce au CPQ, les vendeurs peuvent établir des devis précis et personnalisés en temps réel, tout en tenant compte des remises, des promotions ou des ajustements spécifiques. Aujourd'hui les CPQ tirent majoritairement parti de la 3D pour proposer une visualisation de produit plus réaliste et complète.
Commentaires
Tartare2240
Il y a 9 ans
Bonjour,
Sujet vraiment très intéressant, surtout pour quelqu'un qui, comme moi, utilise GIT sur un projet développé seul pour ne pas "perdre ses sources" en cas de gros problème et pour faire un petit peu de versionning. Ensuite, est-ce que ce n'est pas peut-être un peu trop profond pour les petits projets, ou alors c'est juste une habitude à prendre ?
François DELEGLISE
Il y a 9 ans
Bonjour Tartare, merci pour ton commentaire !
En effet, c'est une habitude à prendre ! En milieu professionnel, tu verras que cette discipline (qui au final est beaucoup plus simple à mettre en place que ce que l'on pense) sera vraiment apprécié de tes confrères (clients, collègues, successeurs...).
En vrai, c'est vraiment rapide... Créer des branches, les fusionner, les supprimer. Comme ça, ça a l'air d'être un process très actif, mais au final, c'est loin d'être contraignant :-) !
Si le projet sur lequel vous travaillez n'est pas encore en ligne, vous pouvez éventuellement vous éviter une hauteur de branche. Cependant, quand le projet entrera en phase d'évolution avec une version stable en ligne, il sera alors vraiment important de conserver cette stabilité en multipliant les sécurités : et le processus indiqué dans l'article fait l'affaire, pour l'instant !