Comment utiliser efficacement git-flow sur un projet dans lequel plus d'une version majeure est maintenue?

J'ai migré plusieurs de mes projets vers le flux de travail git flow, et j'adore ça. Cependant, je n'ai pas trouvé de meilleure pratique qui permette aux choses de se dérouler aussi facilement lorsque vous travaillez avec un projet dans lequel plusieurs versions principales sont maintenues à la fois.

Plus précisément, je ne maintiens pas une "version gratuite" et une "version payante" ou tout autre modèle parallèle, je parle d'un projet dans lequel la version 1 est publiée et reste pris en charge avec les versions mineures (1.1, 1.2, etc. .) jusqu'à la sortie de la version 3, à laquelle les points 2 et 3 seraient maintenus, jusqu'à ce que la version 4 soit publiée ... vous avez l'idée.

Comment avez-vous, ou voulez-vous, gérer deux ou plusieurs versions prises en charge d'un projet à la fois dans un workflow gitflow?

git workflows gitflow

— HedgeMage
source

Je n'ai pas d'exemples d'atm, mais les projets que je connais utilisent des référentiels séparés pour différentes versions principales et des correctifs de backport de l'une à l'autre.

— ProdigySim

@ProdigySim: Merci pour le point de données, mais est-ce juste moi ou cela ajouterait-il une certaine quantité de frais généraux à suivre et à gérer?

— HedgeMage

@ProdigySim Je soupçonne que ces projets n'ont pas utilisé un outil avec les capacités de branchement et de fusion de git.

— Rein Henrichs

@Rein Ils utilisent Mercurial. Je ne pense pas que le branchement serait très propre en termes de suivi des versions majeures parallèles de logiciels.

— ProdigySim

Alors mes soupçons étaient bons. Et oui, c'est assez propre si votre outil le supporte correctement. git et le noyau Linux le font de cette façon.

— Rein Henrichs

Réponses:

man gitworkflows, le grand papa du flux de travail «git flow», décrit les directives générales du flux de travail git; l'utilisation de pu, next, masteret les maintbranches; et comment maintest géré. Si vous avez des branches d'entretien multiples, vous pouvez les nommer, par exemple, maint/1.x, maint/2.xet ainsi de suite.

La clé n'est pas tant de savoir comment utiliser les commandes git, mais comment construire un processus raisonnable. Décidez des éléments importants pour vous (facilité de rétroportage?) Et créez (et documentez) un flux de travail qui satisfait ces contraintes.

— Rein Henrichs
source

Mais cela répond-il à la question? À savoir, git-flow prend-il en charge un modèle de version flexible comme décrit dans la question, ou revient-on aux commandes de base de git? ("gitworkflows" décrit l'utilisation de base du flux de travail git, pré-git-flow.) Git-flow a été créé (ostensiblement) pour simplifier les processus de fusion / branche git, afin que les équipes (avec différents degrés de prouesse git-fu) puissent se concentrer sur le codage et éviter les erreurs de «fusion incorrecte» qui prennent du temps. Est-il possible avec wit-flow de maintenir et de développer la v1.2. {1,2,3, ..} en même temps que la v2.5. {1,2,3, ...}? Peut-être avec des branches de publication à long terme? Ou master1, master2, ...?

— michael

En gros, vous dupliquer les master, releaseet les developbranches pour chaque version majeure , vous êtes maintenant. La façon dont ils interagissent les uns avec les autres reste la même. Pour les featurebranches, il suffit de branche de la branche la plus ancienne vous avez l' intention de fusionner en arrière dans , ce qui empêche en tirant dans les dépendances indésirables. Ensuite, lorsque vous fusionnez votre featurebranche, vous effectuez simplement des fusions supplémentaires dans chaque branche de version principale plus récente appropriée.

— Karl Bielefeldt
source

N'est-ce pas tout l'intérêt de maîtriser toutes les versions publiées?

— HedgeMage

@HedgeMage, dans un cycle de publication plus linéaire, c'est le cas, mais c'est très peu pratique pour les versions majeures parallèles.

— Karl Bielefeldt

Cela semble être la solution la plus pratique, à moins qu'il n'y ait une astuce éprouvée à l'aide de correctifs ou que je ne connais pas. J'ai cherché un moyen d'introduire git-flow et toujours en mesure (comme préalable malheureux) de conserver notre modèle de version existant, où nous devons maintenir / développer des versions plus anciennes (pas seulement des correctifs). Ainsi, v5.1.x restera (avec de nouvelles fonctionnalités ajoutées, des bugs corrigés, etc.) quelques années après la sortie de v6.1.x. Environ 2-3 versions principales prises en charge et développées à tout moment. Mais des corrections de bogues doivent être appliquées à chaque version où le bogue existe.

— michael