Afin de pleinement profiter des fonctionnalités offertes par git, il faut un peu structurer son utilisation. En plus de sa rapidité d’utilisation, le principal avantage de son utilisation est relié à sa capacité de gérer de multiples branches parallèlement et de permettre l’échange de l’historique de développement entre chacune d’elles.
Ce billet est le fruit direct d’une réflexion tirée d’un projet assez complexe sur lequel j’ai mis en place une stratégie de branchage et de déploiement tirant profit de git.
Anciennement, nous utilisions Subversion afin de gérer l’évolution des sources de nos projets. Heureux hasard, notre hébergeur de sources impose une migration à git pour l’automne. C’est de cette façon que git est arrivé dans le portrait.
Vous l’avez probablement vécu. L’histoire est toujours la même. Le travail concurrent sur un projet souvent annonce une source potentielle de conflits dans le code et perte de productivité potentielle en raison d’une erreur ou d’un oubli. C’est pour cette raison qu’il faut structurer l’utilisation de git. D’avoir une stratégie pour la gestion des branches pour votre projet.
En une phrase, avoir une stratégie de branchage git revient à savoir quoi mettre où, au bon moment. Il faut cependant savoir qu’une recette peut ne pas fonctionner pour tous les scénarios. Le moule ne fonctionne pas toujours pour tout le monde.
Lorsque vous utilisez git, le principal intérêt est d’être en mesure de tirer profit de la capacité de git à gérer efficacement plusieurs branches de développement simultanément. Cela veut dire qu’avec git, vous pouvez dire au revoir au modèle de développement utilisant un nombre limité de branches.
Les règles que j’ai mises en place dans notre équipe de développement sont basées sur le principe que les développements à compléter sont d’une durée variable et que leur date de mise en ligne n’est pas fixée dans le béton. Cela veut dire que nous devons travailler parallèlement et sans créer de dépendances entre les différents livrables.
- Une branche doit être créée par par fonctionnalité à livrer ou user story (pour ceux utilisant une méthodologie agile).
- Vous pouvez créer des branches locales pour le développement de petits segments de fonctionnalités ciblées comme les sous-tâches, par exemple.
- rebase d’une branche locale avant le merge dans la branche principale peut-être réalisé, mais n’est pas obligatoire.
- Réaliser un pull des branches sur origin au moment jugé opportun ou à volonté.
- Une branche par étape de déploiement est créée : zone de développements, démo, staging ou production.
- Les tags sont encouragés pour signaler l’évolution de la livraison de votre site.
- Le merge d’une ou des branches sera réalisé sur master uniquement lorsque la mise en ligne est complétée.
- Lorsqu’une branche a subi son merge final, sur master, elle peut être supprimée définitivement.
Avec ces règles, vous pouvez travailler à plusieurs sur le même projet sans que vos développements nuisent à ceux des autres. Depuis que nous l’avons implanté dans notre équipe, la capacité à gérer de multiples développements en même temps sur un site a augmenté. Nous sommes maintenant en mesure de développer en se souciant uniquement de l’intégration de nos changements au moment de les intégrer sur la zone de développements.
L’autre point positif est que nous avons introduit la notion de planification de la livraison de nos changements lorsqu’il est temps de définir les livrables pour la période à venir. Avec cette façon de penser la gestion de nos changements, il est maintenant plus évident de discuter du séquencement des demandes à venir et de la façon de les mettre en ligne.
French Coding 
