Gérer plusieurs versions avec Gitflow

J'ai récemment écrit un article sur Gitflow où j'expliquais ce que c'était et comment l'utiliser dans la plupart des cas.

Depuis, j'ai reçu quelques retours de lecteurs avisés concernant l'utilisation de GitFlow dans des cas plus précis. En particulier dans le cas d'un projet où sont maintenues plusieurs versions.

Expliquons le cas.

Je développe et maintien un framework

Le fonctionnement basique de GitFlow convient, comme nous l'avons vu, dans la plupart des cas. Mais prenons le cas d'une équipe de développement qui s'occupe d'un des derniers frameworks à la mode.

Cette équipe utilise GitFlow et trouve ça génial. Les versions se succèdent et on arrive à la troisième version.

Tous les nouveaux projets de développeurs tiers sont fait dans la dernière version mais il existe encore des projets dans les versions précédentes du framework.

Si une faille de sécurité est découverte, les développeurs tiers s'attendent à ce que l'équipe applique des corrections dans la version 3 mais aussi la version 2.7 du framework. Et c'est normal.

Cette équipe doit donc maintenir deux versions de leur projet en simultané. Notre problème vient du système de branche strict de GitFlow :

• feature : de develop vers develop
• release : de develop vers develop et master
• hotfix : de master vers develop et master

Si les développeurs doivent faire un hotfix sur la version 2.7 du framework (correction de sécurité), ils ne peuvent pas créer la branche concernée à partir du master puisqu'ils sont déjà en version 3 à cet endroit.

Ils ne peuvent pas non plus ré-appliquer les corrections sur master et develop puisqu'en version 3 le code à pu changer du tout au tout et ne serait pas forcément compatible.

Et puis comment représenter ces deux versions simultanée dans l'index de notre projet ?

La branche support

Je ne vous ai pas tout dit sur GitFlow. Il y a une règle moins connue de ce workflow qui peut résoudre notre problème.

Il existe un quatrième type de branche dérivée de master et develop : la branche support.

C'est tout simple :

• La branche support se crée à partir de la branche master sous le format suivant support/2.7.x. Le point de départ doit être le dernier commit de la version 2.7 du projet et non le commit le plus récent de la branche master
• Lorsque vous avez une mise à jour de sécurité à faire sur la version 2.7 vous créez la branche hotfix/2.7.1 depuis la branche support/2.7.x comme s'il s'agissait du master. C'est en fait le master de la version 2.7 maintenue.
• Lorsque la correction est terminée vous faites un merge de votre hotfix sur la branche support.
• Vous supprimez la branche de hotfix et vous taggez v2.7.1 sur la branche support/2.7.x

Dans le projet on a donc :

• master => en version 3.0
• develop => en cours de développement de la version 3.1
• support/2.7.x => en version 2.7
• feature/...
• release/...
• hotfix/...

Un peu d'automatisation ?

Oui et non. Cette fonctionnalité, même si elle est très simple à appliquer pour un humain, reste compliquée à implémenter pour qu'une machine l'automatise.

Il y a donc bien des commandes git flow support ... mais elles sont encore en développement/test/expérimentation. En plus, elles ne sont pas beaucoup documentées.

Vous pouvez les utiliser mais il risque d'y avoir quelques bugs. Si vous avez l'âme aventureuse allez-y, ça ne pourra qu'aider le développeur mais évitez les projets critiques...

Si vous avez des questions ou des remarques/conseils, n'hésitez pas à laisser un commentaire plus bas ! Je serais ravis de vous lire. Et si vous aimez l'article, n'oubliez pas de le partager avec vos amis.