Introduction
Tout d’abord, soyons honnête, ce tutoriel n’a pas pour vocation d’être une bible GIT ! Simplement, j’ai pour ma part un peu « ramé », « pataugé », « galéré » (ndla: Pourquoi ces expressions sont toutes des sports d’eau ? je nage très bien moi !) et mon objectif via ce tutoriel est de vous éviter de perdre autant de temps que moi. C’est sympa non ? L’idée est de vous donner de manière claire et efficace les grandes lignes d’une gestion sous git pour être rapidement opérationnels. Ces bonnes pratiques couplées à la mise en place de jenkins vont rendre votre projet très performant.
L’organisation des branches
Il est très important de bien séparer vos branches. Git permet cette souplesse et cette rapidité de passage d’une branche à l’autre par rapport à SVN qu’il serait dommage de ne pas exploiter. Traditionnellement votre projet devra se découper en trois branches. je vous en propose un schéma ci-dessous:
Master : La branche de la version en production
C’est la branche par défaut. C’est également celle que vous déploierez sur votre environnement de production. Il est important de vous imposer de ne réaliser aucune modification directement dans cette branche. Sinon bonjour, les risques de régression et les conflits de merge.
Hotfix : La branche des bugs en production
C’est la branche que tirerez depuis master à chaque fois que vous aurez un ou plusieurs correctifs à faire sur votre environnement de production. Vous tirerez une branche hotfix de laquelle vous tirerez autant de branche hotix_n1, hotfix_n2 que vous aurez de correctifs à réaliser. Une fois terminé, vous pourrez tester la branche hotfix sur votre environnement d’intégration avant de la merger dans master. Une bonne pratique, d’ailleurs très repandue consiste à indiquer le numéro de ticket / mantis que vous corrigez dans le nom de la branche que vous venez de créer et réciproquement d’indiquer le nom de la branche en commentaire du ticket du bug concerné. Cela vous permettra une vrai tracabilité.
Develop : La branche des nouvelles améliorations
C’est la branche de laquelle partiront toutes vos évolutions. Il est important que toute modification faite dans master soit également répercutée par un merge dans Develop. Sans quoi vous risquez de réaliser de nouvelles features non compatibles avec des patchs précédents. Bien entendu vous pouvez créer d’autres branches depuis develop, je vous recommande même de créer une branche par groupe fonctionnel afin de pouvoir tester vos différents développements de manière segmentés. Develop contrairement à Hotfix se doit d’être perpétuelle, en effet vous serez susceptible de rattacher une configuration précise en gérant les droits de votre équipe. Par exemple l’administrateur sera obligé de valider chaque demande de merge au sein de develop (et donc de master ensuite)
