Flux de travail Git approprié pour plusieurs versions actives lors de la gestion des correctifs

J'essaie de choisir un flux de travail Git qui convient le mieux à notre produit. Voici les paramètres:

• Nous faisons quelques sorties majeures par an, disons 10 au maximum
• Nous avons plusieurs versions de notre produit actives en même temps (certaines personnes sont sur v10.1, certaines sur v11.2, etc.)
• Nous devons être en mesure de travailler sur plusieurs versions en même temps (afin que nous puissions travailler sur la version 12.1, mais à la fin de la version, nous commençons à travailler sur la version 12.2 en même temps)
• Nous devons pouvoir corriger les versions lorsque des bogues critiques sont détectés

Jusqu'à présent, voici comment je pense que cela pourrait fonctionner:

• Un seul dépôt à distance est utilisé
• Créer la branche 12.1 à partir du maître
• Créez des branches de fonctionnalités basées sur 12.1, validez-les et fusionnez à nouveau dans 12.1, appuyez sur
• Une fois que nous devons commencer à travailler sur la future version, créez une nouvelle branche 12.2 basée sur 12.1
• À partir de là, lorsque vous travaillez sur une fonctionnalité pour 12.1, créez une branche à partir de 12.1, validez les modifications et fusionnez dans les deux 12.1 et 12.2, appuyez sur
• Si vous travaillez sur une fonctionnalité pour 12.2, créez une branche à partir de 12.2, validez les modifications et fusionnez uniquement dans 12.2, appuyez sur
• Lorsque la version 12.1 est terminée, fusionnez-la dans la branche master et tag master avec 12.1
• Si un correctif est nécessaire, créez une branche de correctif à partir de la plus ancienne branche de version qui en a besoin, validez les modifications et fusionnez à nouveau dans toutes les branches de version pour cette version et les versions futures qui pourraient être affectées; si la dernière branche de version stable a été affectée, fusionnez-la dans master.

J'ai quelques inquiétudes:

• Je ne suis pas sûr que la fusion de correctifs à partir d'anciennes branches dans de nouvelles branches sera un processus fluide, surtout s'il y a eu beaucoup de changements qui se chevauchent; serait-il plus judicieux de simplement corriger manuellement dans chaque branche dans les cas où il semble y avoir des conflits
• Les modèles de workflow que j'ai vus semblent ne pas garder les branches des versions en vie, une fois cela fait, la version est fusionnée dans master, étiquetée et supprimée. Mon problème avec cela est que je n'ai pas une bonne idée de comment gérer l'état de la version si je n'ai que des balises dans le master, semble plus facile à corriger dans une branche et puis j'ai une version à laquelle je peux toujours revenir qui a le dernier correctif (je peux même marquer les correctifs dans la version). Je ne suis pas sûr qu'il y ait un moyen de revenir en arrière dans master et d'une manière ou d'une autre d'avoir une copie de la version avec des correctifs appliqués et de mettre à jour cette balise.

Les commentaires sont appréciés sur les choses que j'ai peut-être négligées ou sur les meilleures façons d'accomplir les choses compte tenu des exigences que j'ai spécifiées.

Vous semblez bifurquer sur chaque version majeure (12.0.0), puis avoir des mises à jour mineures possibles pour chacune (12.1.0) et des correctifs (12.2.1). Correct?

Il n'y a pas de raison spécifique pour laquelle vous ne pouvez pas garder les branches de version actives dans GitFlow après la sortie d'une version, à part le fait que la coordination des changements entre plusieurs branches divergentes pendant une longue période est difficile avec n'importe quel modèle. Je suppose que GitFlow a également été modélisé davantage pour les produits qui conservent une seule version en direct tout en développant la suivante.

Je resterais avec GitFlow et apporterais quelques amendements;

Ignorez la branche principale. Je ne l'ai pas utilisé jusqu'à présent, et il perdrait sa linéarité dans la façon dont vous travaillez. Continuez le développement sur la prochaine version majeure de develop. Si vous décidez de garder master, ne mettez pas de balises de release sur master, placez-les sur le dernier commit sur la branche release qui a produit le binaire que vous expédiez.

Ne jetez pas les branches de publication après les avoir fusionnées pour les développer. Au lieu de cela, conservez-les pour la prochaine version mineure et les éventuels correctifs. Si jamais vous arrêtez de supporter une version, je suppose que c'est bien de les supprimer. Vous pouvez nommer les branches de publication d'après leur composant principal, version / 12, puis créer des branches de sous-version, version / 12.1, version / 12.2. Je n'ai pas eu à me soucier trop de ce niveau de parallélisme, mais c'est probablement ce que j'essaierais. Dans ce cas, vous pouvez considérer chaque branche de version principale comme son propre environnement sous-GitFlow.

Si vous devez travailler en parallèle sur les fonctionnalités de plusieurs futures versions majeures en même temps, vous devrez peut-être garder la prochaine (13) sur le développement et quoi que ce soit pour les versions ultérieures (14, 15) sur les branches "develop-N" supplémentaires . Cela semble très difficile à maintenir en général, mais ce serait possible.

Il semble qu'une solution possible à votre problème principal ( «Nous devons être capables de travailler sur plusieurs versions en même temps [...]» ) consiste à faire ungit worktree add <path> [<branch>]

Un référentiel git peut prendre en charge plusieurs arborescences de travail , vous permettant de vérifier plus d'une branche à la fois.
Avec git worktree add, une nouvelle arborescence de travail est associée au référentiel.

Ce nouvel arbre de travail est appelé "arbre de travail lié" par opposition à "l'arbre de travail principal" préparé par " git init" ou " git clone" .
Un référentiel a une arborescence de travail principale (s'il ne s'agit pas d'un référentiel nu) et zéro ou plusieurs arborescences de travail liées.

Voir cette réponse SO pour une introduction détaillée sur git worktree.

Vous avez mentionné que vous connaissiez gitflow. Je suggère de l'adopter pour votre scénario. Vous devrez créer des branches à partir de votre branche de développement pour prendre en charge les anciennes versions. Ces anciennes versions devront également avoir leurs propres branches de version / master et branches de correctif. Vous devrez fusionner périodiquement vos branches de support dans les nouvelles branches de support et la branche de développement.

À mesure que le développement des versions principales diverge, cela deviendra de plus en plus difficile. Il n'y a pas de solution miracle pour cela. Parfois, il sera plus facile d'effectuer des modifications manuellement. Le coût de la maintenance des anciennes versions augmentera, et à un moment donné, cela n'en vaudra plus la peine.

Tout dépend du type de changements que vous apportez dans vos anciennes versions. Si ce n'est que la correction de bugs, c'est relativement facile à fusionner. Si vous essayez d'ajouter de nouvelles fonctionnalités, ce sera difficile.