Come si può usare efficacemente git-flow su un progetto in cui viene mantenuta più di una versione principale?

Ho migrato molti dei miei progetti nel flusso di lavoro git flow e lo adoro. Tuttavia, non ho trovato le migliori pratiche che mantengano le cose fluide in modo fluido quando si lavora con un progetto in cui viene mantenuta più di una versione principale alla volta.

In particolare, non sto mantenendo una "versione gratuita" e una "versione a pagamento" o qualsiasi altro modello parallelo, sto parlando di un progetto in cui viene rilasciata la versione 1 e rimane supportato con versioni secondarie (1.1, 1.2, ecc. .) fino al rilascio della versione 3, a quel punto i punti 2 e 3 verrebbero mantenuti, fino al rilascio di 4 ... si ottiene l'idea.

In che modo hai, o vorresti, mantenere contemporaneamente due o più versioni supportate di un progetto in un flusso di lavoro gitflow?

man gitworkflows, il nonno del flusso di lavoro 'git flow', descrive le linee guida generali sul flusso di lavoro git; l'uso di pu, next, mastere maintrami; e come maintviene gestito. Se si dispone di più rami di manutenzione, è possibile denominarli, ad esempio maint/1.x, maint/2.xe così via.

La chiave non è tanto come usare i comandi git, ma come costruire un processo ragionevole. Decidi quali cose sono importanti per te (facilità di backport?) E crea (e documenta) un flusso di lavoro che soddisfi questi vincoli.

In sostanza, si dovrebbe duplicare il master, releasee developrami per ogni versione principale si gestiscono. Il modo in cui interagiscono tra loro rimane lo stesso. Per featurerami, basta assicurarsi di ramo dal ramo più antico che si intende fondersi di nuovo in , che impedisce tirando in dipendenze indesiderate. Quindi quando unisci featurenuovamente il tuo ramo, fai solo ulteriori fusioni in ogni ramo della versione principale più recente appropriata.