Dans cette article je pars du principe que tu connais les commandes git ainsi que le vocabulaire tel que Pull Request / Merge Request. Si ce n’est pas le cas n’hésite pas à lire l’article dédié aux bases de git avant celui ci.
Ici tu vas apprendre comment organiser tes branches pour bien gérer le cycle de vie de tes projets. On va commencer par les bases avec seulement les branches basiques pour arriver jusqu’à la structure la plus complexe que tu peux trouver dans une entreprise. A toi d’estimer jusqu’où aller selon ton projet.

La base

Commence par créer 2 branches :

• main : c’est le code qui tourne en production
• develop : c’est le code qui est en cours de développement

A partir de develop quand tu veux ajouter une fonctionnalité, tu vas préfixer ta branche par feature/ puis mettre le nom de ta fonctionnalité.

• exemple : feature/add-title-to-welcome-page, feature/add-article-to-welcome-page

Pour chacune de ces branches quand tu as terminé (donc réalisé ton/tes commits), tu peux les merger dans develop via une PR / MR.

Dès que develop a assez avancé pour être considérée comme une nouvelle release, merge develop vers main
Cela implique en général une mise en production du code de la branche main. C’est souvent automatisé via un Continuous Delivery, on en parle dans l’article dédié à la CI / CD.

Ca c’est le minimum vital, maintenant comment faire si tu te rends compte qu’en production il y a des bugs ?

Hotfix

Dans ce cas tu vas tirer une branche de main que tu préfixes par hotfix/

• exemple : hotfix/correct-link-welcome-icon, hotfix/popup-doesn-t-close

Dès que tu as terminé ta correction tu merges sur main ET sur develop

Selon ton cycle de vie de projet tu peux aussi estimer ne faire aucune correction et donc tes bugs seront dans la prochaine version de develop que tu mergeras sur main. Tu peux alors prefixer ces corrections dans bufix/ au lieu de feature/
– exemple : bugfix/correct-link-welcome-icon

Tu peux aussi répartir : créer des hotfix pour les bugs important et bloquant et des bugfix pour ceux qui peuvent attendre la prochaine livraison

Pour éviter d’avoir trop de bug qui arrive en productions on va préférer avoir un voir plusieurs environnements intermédiaires.

Environnements

Entre develop et main, il est courant d’avoir une ou plusieurs branches intermédiaires qui sont dédiées à être testées dans un autre environnement que le developpement avant mise en production. On peut trouver :

– staging : intégration technique avant de passer à la validation métier.
– qual / qa / uat : validation métier : les équipes dédiées vont tester nos développements pour valider qu’ils correspondent aux attentes
– preprod : simulation complète de la production, on reproduit l’environnement de production à l’identique pour tester la livraison réelle.

Selon le projet tu peux avoir plus ou moins tous les étages. Par exemple il est possible de n’avoir que preprod et il regroupera les besoins des 3 à la fois : tests par les métiers, la technique et sera en conditions de production.

ATTENTION HOTFIX : Avoir ces branches en plus implique que si tu fais des hotfix sur l’un des étages alors il faudra les répercuter sur les étages inférieurs. C’est pour cela que cela ajoute une certaine lourdeur à ton organisation git donc adaptée pour des projets conséquents.
Il est donc important d’adapter le nombre d’environnement à la taille de ton projet. Petit projet perso, juste preprod voir aucun. Gros projet d’entreprise avec plusieurs services impliqués dans le développement du logiciel…la totale !

Petits ou grands projets il est pratique de gérer des versions

Gérer les releases

Première chose, quand tu as mergé vers main, créer un tag sur main portant le semver de ta version :
git tag -a v1.2.0 -m « Release version 1.2.0 »

C’est le minimum pour gérer des versions, maintenant tu peux aller plus loin en ayant des branche dédiées que tu préfixes par release/

• exemple release/v1.0.2, release/v1.0.3

Tu pourras ainsi revenir facilement à une ancienne version en cas de besoin. Mettons qu’il y ai le feu en production revenir à un tag ou bien avoir le code d’une release ancienne en production le temps de régler les soucis est alors tout à fait possible

Au final

Ton organisation de branche va imbriquer plus ou moins de branches selon la taille de ton projet et tes besoins
Au minimum tu devras avoir une branche develop et main et réaliser tes devs dans develop pour les pousser vers main une fois prêts.
Pour assurer le moins de bugs possibles en production, des environnements intermédiaires peuvent être mis en place afin de tester les non régressions, bug ou simplement que ce qui a été développé correspond à ce qui est demandé

Maintenant si tu veux mettre en place un déploiement automatique quand du code est mergé dans un environnement c’est par ici (lien Continuous Developpment). Tu peux également mettre en place une vérification automatique avant qu’un merge soit réalisé vers une environnement par ici (lien Continuous Intégration).

Bon à savoir

Git flow a été à l’origine une proposition de Vincent Driessen dans son blog et devenu petit à petit un standard dans l’industrie du développement
lien de son article : https://nvie.com/posts/a-successful-git-branching-model/

Il existe d’autre modèle de stratégie de branches
– https://docs.github.com/en/get-started/using-github/github-flow