J'essaie de choisir un flux de travail Git le plus approprié pour notre produit. Voici les paramètres:
Jusqu'à présent, voici comment je pense que cela pourrait fonctionner:
J'ai quelques inquiétudes:
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 conserver 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 en mesure de travailler sur plusieurs versions en même temps [...]") consiste à faire un git 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.
Avecgit 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 this SO answer 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.