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:

Bonjour,
je commence à m’intéresser à Git et j’en suis pour l’instant à la recherche de mon organisation des branches… Votre article rentre donc tout à fait dans ce cadre !
Suite à cette lecture j’ai 2 questions.
1° Si j’ai bien compris (et apparemment les commandes Git le permettent) la branche SUPPORT pour la V2.7.x peut/doit être créée a posteriori (cad quand la MASTER V3 (ou plus) existe).
2° La seconde question découle de la structure GitFlow et de mon architecture logicielle actuelle (pas facile a exposée…). Aujourd’hui j’ai un framework “maison” de plus de 40 DLL (évolutif). Chaque DLL correspond à une solution VisualStudio. Bien évidemment certaines DLL sont dépendantes les unes des autres. Pour faciliter l’utilisation de mon framework j’ai créé un répertoire “Framework” dans lequel je copie automatiquement toutes mes release de mes DLL. De ce fait chacun de mes programmes fait référence au DLL du répertoire “Framework” et non pas à tous mes répertoires “solution” (plus facile pour ajouter les références à un projet. Ma question : si je fais un retour arrière sur une DLL “X” (V3 en V2.7 par exemple), je dois aussi faire un retour arrière pour toutes les DLL qui sont en référence de cette DLL “X”. C’est donc du boulot et ça m’oblige à connaitre les versions que je dois utiliser pour toutes mes DLL en référence (car chacune évolue indépendamment). Auriez-vous un conseil à me donner par rapport à mon organisation ?
Merci

Bonjour et bienvenu @babe59 ! :tada:

Pour la première question : effectivement il est possible de créer les branches à posteriori. Ça peut être le cas pour les branches support/ mais souvent les versions que l’on décide de maintenir malgré le passage à une nouvelle version sont connues à l’avance, on créera donc la branche support/ correspondante lors du (dés le) passage à la nouvelle version.

Pour la deuxième question c’est un peu plus compliqué car cela dépend vraiment de l’environnement de travail/développement de chacun et de la techno (ici visual studio / .NET ? que je ne connais pas). Mais je pense que le plus adapté dans votre cas est l’utilisation d’un gestionnaire de dependances/paquets/versions (je ne sais pas si ça existe pour visual studio). Gitflow pourra dans tous les cas être utile a votre workflow.

J’espére avoir répondu à vos questions :slight_smile: