Nossa linha de produtos de software requer o desenvolvimento e manutenção de várias versões de software simultaneamente. Somos novatos em relação ao Git e recentemente adotamos o Git Flow para aproveitarModelo de ramificação de Driessen. Temos uma equipe de software muito pequena, com poucos desenvolvedores dedicados (todos usamos muitos chapéus) e nenhum "guru da integração".

Muitas pesquisas revelaram poucos conselhos específicos sobre como adaptar o Git e o Git Flow às nossas necessidades. O que aconteceu é que o Git Flow não é adequado para suportar múltiplas versões simultaneamente. 1discussão relacionada sobre SO tem respostas indicando nomes de ramificações separadas que precisam ser usados ​​para rastrear históricos de versões separadas. Isso e estratégias relacionadas eliminam o Git Flow, a menos que ele seja modificado; veja as limitações da nossa equipe acima por uma razão pela qual isso não é prático para nós.

A questão-chave é o que os outros acharam ser uma boa abordagem para implementar o modelo de ramificação da Driessen o mais próximo possível, ao mesmo tempo em que suportam múltiplas linhas de lançamento.

ATUALIZAÇÕES:

Destilar as respostas abaixo (particularmente @Rasmus ') com buscas mais específicas e discussões internas sobre algumas opções leva à seguinte solução que estamos implementando, e que eu ofereço como uma abordagem que pode ser relevante para equipes similares sob condições similares.

Não continuaremos usando o Git Flow. Em vez disso, aplicaremos o modelo de Driessen a cada linha individual de lançamento em um repositório, precedendo cada nome de ramificação com sua sequência de liberação pretendida, por exemplo:

r1.5/develop

Todas as versões de um projeto estão contidas no repositório Git. Iniciar uma nova versão de projeto consiste em criar um pequeno conjunto de novos ramos de vida longa prefaciados pela string de lançamento (por ex.r1.6/develop e, no nosso caso,r1.6/release; nãomaster com sua implicação do estado atual único bom buildable).

Estabelecemos um repositório público central por projeto em um servidor que será a principal via para compartilhamento de código através de repositório localremote links. Um push para este repositório significa código pronto para ser consumido por outros. FusãoRX.Y/develop em e, em seguida, empurrando oRX.Y/release ramificação significa o código destinado à liberação.feature, hotfixet. al. ramos são tratados de forma semelhante. O histórico de mesclagem / confirmação de ramificação para uma determinada linha de liberação é limpo e compreensível. Não queremos a típica estratégia de recompra distribuída do Git em favor de evitar a complexidade de fundir essas recompras que, ao longo do tempo, tendem a divergir na estrutura.

Em algumas GUIs do Git (como o SourceTree, por exemplo), essa estrutura de ramificação é reconhecida e exibida como hierárquica, o que ajuda a entender o histórico de nível superior de um projeto a partir da estrutura de ramificação.

Desculpas por não votar em cima de qualquer resposta; minha reputação em SO ainda não é o mínimo exigido para isso.