Qual é a maneira recomendada para separar o desenvolvimento atual do desenvolvimento de manutenção no software de controle de versão?

Eu tenho alguns aplicativos gerenciados usando o Git. Acabei de lançar uma nova versão 2.x que pretendo manter a longo prazo (principalmente as correções de bugs). Enquanto isso, gostaria de começar a trabalhar na versão 3.x. Qual é a maneira recomendada de gerenciar isso? Devo criar uma ramificação para a versão 2.xe ter o desenvolvimento 3.x no mestre? ou o contrário?

version-control git

— Laurent
fonte

Tem ramos diferentes para o desenvolvimento e estável.

— Oded

Então, o que geralmente entra no ramo mestre? (até agora, eu sempre faço tudo por lá) #

— laurent laurent

Você precisa decidir o que você quer masterdizer. É apenas um rótulo.

— Oded

Respostas:

Uma maneira muito interessante de fazer as coisas foi descrita aqui: Um modelo de ramificação Git bem-sucedido

Achei muito intrigante, mas ainda não o usei.

Muito bem, conforme solicitado, um resumo (muito) breve do que o artigo diz:

A ramificação Mestre apenas representa todos os marcos concluídos (por exemplo, Versão 1.0, 1.1, 1.2 etc.)
O desenvolvimento é feito em seu próprio ramo (convenientemente chamado de "desenvolver", quem teria pensado?). A ramificação de desenvolvimento é mesclada de volta à ramificação Mestre, sempre que uma versão completa do recurso é concluída.
Ramificações do desenvolvimento são ramificações de recursos. Eles representam recursos únicos para a próxima versão (ou qualquer futura). Eles se fundem novamente com o ramo de desenvolvimento.
Outro ramo que vem do desenvolvimento é o ramo "release". Esta é uma ramificação que representa uma versão quase completa, na qual apenas pequenos detalhes precisam ser limpos. Ele se funde com o ramo de desenvolvimento e, finalmente, com o ramo Master
O "Hotfix" ramifica a ramificação da ramificação principal se você encontrar um bug grave em uma de suas versões (ou seja, "Se o uso digitar o código konami, nosso programa reformatará o disco rígido principal ..."). Ele se ramifica a partir da versão de buggy e, quando a correção é concluída, é mesclada novamente na ramificação mestre E na ramificação do desenvolvimento.

É o que falta, mas confie em mim, que o artigo o descreve de maneira mais detalhada e, com o gráfico de visualização útil, é muito mais fácil entender.

— Sorcy
fonte

Você deve incluir alguma explicação sobre sua sugestão na resposta, de preferência as pessoas não terão que seguir o link para ter uma idéia geral do modelo. Ligações têm o mau hábito de ir awol, e respostas devem ficar por conta própria ...

— yannis

+1 Praticamente o que usamos no trabalho, e realmente funciona.

— Ed James

Eu acredito que isso é comumente referido como o modelo "tronco estável" ou "ramo de recurso".

— sleske

"A ramificação mestre apenas representa todos os marcos concluídos (versão 1.0, 1.1, 1.2 etc.)" Eu não gostaria de uma ramificação mestre com as versões 1.0, 1.1, 1.2, 2.0, 1.3, 2.1, 1.4, 2.2, 3.0, 1.5 em essa ordem, isso seria realmente confuso. Meu palpite é que existe uma suposição implícita de que há no máximo um fluxo no qual os lançamentos são feitos, esse não é o caso em minha prática. Existem adotantes precoces e pessoas querendo algo mais estável.

— AProgrammer

Bem, a longo prazo, um ramo nada mais é do que um rótulo para facilitar a você saber o que está acontecendo lá. Portanto, se você não gostar dessa maneira, não há nada que o impeça de usar a ramificação Master apenas para versões estáveis do prefeito e ter uma ramificação "Trial" (ou o que você quiser chamar) para versões incrementais menores.

— Sorcy

Meu princípio é que, quanto mais curto for o ramo, mais profundo ele será na estrutura do ramo e mais específico será o seu nome. Quanto mais longo o ramo, menor será a sua estrutura e mais genérico será o nome.

Portanto, você mantém seu mestre na versão de longo prazo (3.X) e continua nomeando esse ramo com um nome genérico (mestre, tronco, desenvolvimento, ...) e não um específico (nome do código de versão ou números de versão ainda piores) na prática, dependem demais da decisão de comercialização tardia)

Não importa tanto em um sistema como o git, que possui um espaço de nome simples para ramificações e onde ramificações são equivalentes. Importa mais com um sistema como clearcase que possui um espaço de nome hierárquico para ramificações (o nome completo da ramificação V4 acaba sendo principal / v1 / v2 / v3 / v4 ...)

— AProgrammer
fonte

+1, exceto que eu não sei o que profundo e superficial realmente significa nesse contexto, talvez você possa expandir um pouco esses termos?

— quer

Pensa em galhos fazendo uma árvore. Eles podem sair do tronco ou de outro ramo. Raso significa que o número de etapas de ramificação entre a ramificação e o tronco é pequeno, profundo significa que o número de etapas de ramificação é importante. O que é pequeno e importante é principalmente relativo, mas vi esquemas para os quais cada novo lançamento foi um passo além do anterior do tronco. Se você estiver usando um espaço para nome simples, isso não é tão ruim. Se o espaço para nome for hierárquico (clearcase, CVS, RCS, Perforce também pode ser usado dessa maneira), você obterá nomes cada vez mais longos.

— APROGRAMMERJ #