Como alguém pode usar o git-flow efetivamente em um projeto no qual mais de uma versão principal está sendo mantida?

Migrei vários dos meus projetos para o fluxo de trabalho do git flow e estou adorando. No entanto, não encontrei uma prática recomendada que mantenha as coisas fluindo da mesma maneira ao trabalhar com um projeto no qual mais de uma versão principal é mantida por vez.

Especificamente, não estou mantendo uma "versão gratuita" e uma "versão paga" ou qualquer outro modelo paralelo, estou falando de um projeto no qual a Versão 1 é lançada e permanece compatível com versões secundárias (1.1, 1.2, etc. .) até a versão 3 ser lançada, quando os pontos 2 e 3 seriam mantidos, até a liberação de 4 ... você entendeu.

Como você mantém ou mantém duas ou mais versões suportadas de um projeto ao mesmo tempo em um fluxo de trabalho do gitflow?

git workflows gitflow

— HedgeMage
fonte

Não tenho exemplos de atm, mas os projetos que conheço usaram repositórios separados para diferentes versões principais e patches de backport de um para o outro.

— ProdigySim

@ProdigySim: Obrigado pelo ponto de dados, mas sou apenas eu ou isso adicionaria uma certa quantidade de sobrecarga para rastrear e gerenciar?

— HedgeMage

@ProdigySim Suspeito que esses projetos não usaram uma ferramenta com os recursos de ramificação e mesclagem do git.

— Re

@ Rein Eles usam Mercurial. Não acho que a ramificação seja muito clara em termos de rastreamento das principais versões paralelas de software.

— ProdigySim

Então minha suspeita estava correta. E sim, é bastante limpo se sua ferramenta suportar adequadamente. O git e o kernel do Linux fazem desta maneira.

— precisa saber é o seguinte

Respostas:

man gitworkflows, o avô do fluxo de trabalho 'git flow', descreve as diretrizes gerais do fluxo de trabalho git; o uso de pu, next, mastere maintfiliais; e como mainté gerenciado. Se você tiver várias ramificações de manutenção, poderá nomeá-las, por exemplo maint/1.x, maint/2.xe assim por diante.

A chave não é tanto como usar os comandos git, mas como criar um processo razoável. Decida o que é importante para você (facilidade de backporting?) E crie (e documente) um fluxo de trabalho que atenda a essas restrições.

— Rein Henrichs
fonte

Mas isso responde à pergunta? Ou seja, o git-flow suporta um modelo de versão flexível, conforme descrito na pergunta, ou é revertido para os comandos básicos do git? ("gitworkflows" descreve o uso básico do fluxo de trabalho git, fluxo pré-git.) O fluxo git foi criado (ostensivamente) para simplificar os processos de mesclagem / ramificação git, para que as equipes (com diferentes graus de proeza git-fu) possam se concentrar na codificação e evitar erros demorados de "má fusão". É possível que o w / git-flow mantenha e desenvolva a v1.2. {1,2,3, ..} ao mesmo tempo que a v2.5. {1,2,3, ...}? Talvez com ramificações de liberação de longo prazo? Ou master1, master2, ...?

— michael

Basicamente, você iria duplicar os master, releasee developramos para cada versão principal você está mantendo. Como eles interagem entre si permanece o mesmo. Por featureramos, apenas certifique-se filial a partir o ramo mais antigo você pretende fundir para trás em , o que impede puxando em dependências indesejadas. Então, quando você mescla sua featureramificação novamente, basta fazer mesclagens adicionais em cada ramificação da versão principal mais nova apropriada.

— Karl Bielefeldt
fonte

O objetivo principal do mestre não é incluir todas as versões lançadas?

— HedgeMage

@ HedgeMage, em um ciclo de lançamento mais linear, mas é altamente impraticável para versões principais paralelas.

— Karl Bielefeldt

Essa parece ser a solução mais prática, a menos que exista algum truque comprovado usando hotfixes ou coisas que eu não conheço. Eu tenho procurado uma maneira de introduzir o git-flow e ainda ser capaz de (como um pré-requisito infeliz) manter nosso modelo de versão existente, onde precisamos manter / desenvolver versões mais antigas (não apenas hotfixes). Portanto, a v5.1.x permanecerá por aí (com novos recursos adicionados, bugs corrigidos etc.) alguns anos após o lançamento da v6.1.x. Cerca de 2-3 versões principais são suportadas e desenvolvidas a qualquer momento. Porém, correções de bugs precisam ser aplicadas a cada versão em que o bug existe.

— 11133 Michael