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.


This is a companion discussion topic for the original entry at https://blog.nathanaelcherrier.com/fr/gerer-plusieurs-versions-avec-gitflow/
1 Like

Bonjour Nathanael.

Je suis toujours très intéressé par tout ce qui nous aide à maitriser git et gitflow en fait partie. J’avais posé une fois la question à “un expert” sur comment gérer plusieurs versions et ça réponse me paraissait fumeuse et pas adaptée. La votre en revanche me parait tout à fait bonne.

Cependant, j’ai une question subsidiaire. Dans la mesure où la gestion des “anciennes” versions se fera par une branche dédiée (ici support/2.7.1) pourquoi ne pas créer systématiquement cette branche à chaque fois qu’on crée une version.
Cela se substituerait aux traditionnels tags en évitant d’être en “Head Detached” quand on veut checkout une version donnée et être prêt à faire évoluer cette version (pas forcément que des fix de bug).
Dans cette optique, j’aurais astucieusement utilisé le mot clé version/ plutot que support/ car ca permettrait au-delà d’assurer simplement le support de faire vivre toutes les versions existantes.
Dans cette démarche la branche master héberge uniquement les versions majeures (vX) et toutes les branches versions issues de master sont des mineures (v2.X) et de manière fractale on peut avoir des branches de fix (v2.7.x) issues de ces branches mineures.
L’arborescence git serait alors le reflet du versioning sémantique.

Qu’en pensez-vous ?

Je pense que tout faire avec des branches pourrait compliquer la maintenance du repo et beaucoup de ces branches serait (à mon avis) inutiles.

Par exemple, dans la plupart des cas je ne veux pas gérer toutes les versions en parallèle. On perdrait l’aspect chronologique des versions. Il s’agit plutôt d’un besoin ponctuel et souvent temporaire.

Comment gérer le fait que j’ai en même temps dans mon projet une branche version/v2.x et une branche fix/v2.7.x ? Lorsque j’ai une correction à faire je dois la faire où ? Il n’y a pas de sens à coder le fix sur version/v2.x si j’ai une branche fix/v2.7.x. Mais il n’y pas plus de logique à le coder sur fix/v2.7.x sans que le le fix ne soient aussi appliqué à version/v2.x puisqu’il est censé contenir la v2.7.
Ce qui nous oblige donc sans arrêt à essayer de synchroniser nos branches et qui pourrait mener à des erreurs de manipulations, etc.

C’est pour ça que je pense que créer des branches de support uniquement lorsque l’on souhaite supporter plus longtemps une version et laisser l’identification chronologique des versions au tags est mieux. Ce qui fait que l’on ne crée ce genre de branches que lorsque les historiques ont/vont diverger, elles ne sont donc plus liés entre elles.

Pour le detached head, ça ne me dérange pas car je ne développe pas sur une version précédente / un tag. Les seuls endroits où j’ai besoin d’appliquer des modification au code sur le HEAD de master ou le HEAD d’une des branches de support qui continue à vivre.

Si vraiment j’ai besoin de travailler depuis une version précise, je peux créer une branche à partir du tag ce qui fait que je ne suis jamais en detached head.

1 Like

Au passage, bienvenue sur le forum ! :tada: