Para onde vão as correções no modelo git-flow?

Nos hotfixes do modelo Git-flow , comumente referidos como, vão em sua hotfix-*ramificação específica e pequenas correções de integração imediatamente antes do lançamento na release-*ramificação. As correções gerais da versão anterior não parecem ter um lugar.

Onde eles devem aparecer? Eles deveriam estar em seu próprio bug-*ramo ramificado develop(exatamente como featureramos)?

git gitflow

— Sapato
fonte

Por que um bug não crítico no código liberado seria diferente de um pequeno recurso para produzir um comportamento diferente do que o aplicativo atualmente faz?

— Bart van Ingen Schenau

@BartvanIngenSchenau Você está recomendando que sejam feature-*filiais? A correção de um comportamento incorreto pode ser vista como um recurso?

— sapato

@ Sapato Acho que o que Bart quer dizer é que você deve tratá-los como recursos, não necessariamente usando o mesmo prefixo de ramificação .

— precisa saber é o seguinte

@Shoe: em git-flow, qualquer ramo, exceto master, develop, release-*ou hotfix-*é um ramo de funcionalidade, assim você pode usar qualquer prefixo que você gosta e usar um prefixo diferente para bugs. Além disso, qual é a diferença entre comportamento incorreto que funciona como especificado e comportamento incorreto que se desvia da especificação? Nos dois casos, é um comportamento incorreto, mas apenas o último é um bug.

— Bart van Ingen Schenau

A resposta curta: Sim, as ramificações para correções de erros que estão entrando em uma próxima liberação planejada devem estar nas ramificações dos recursos. Como você nomeia ramos de recursos ou esses ramos para correções de bugs depende de você e dos padrões da sua equipe, mas eles devem ser tratados de forma idêntica se você estiver seguindo o Gitflow.

O comentário de Bart van Ingen Schenau traz um bom ponto.

Gitflow tem cinco tipos de filial: master, develop, ramos de hotfix (prefixados com hotfix-), ramos de libertação (com prefixo release-e ramos O recurso. masterE developramos são de longa duração ramos e você não comprometer diretamente neles As. release-Ramos são feitos para desenhar uma linha para uma versão específica e, em seguida, dê suporte a correções de erros entre a identificação da próxima versão e a versão.Os hotfix-ramos são especificamente para lançamentos críticos fora do ciclo de produção.Os feature-ramos são para o desenvolvimento de recursos individuais para algum lançamento futuro.

Vindo de ambientes onde PRs são usados e para além de um desenvolvedor individual se comprometer com um ramo de funcionalidade, nada deve ser cometido diretamente master, developou um ramo release. Isso garante que todas as alterações sejam revisadas por código, além de garantir a cobertura apropriada dos testes e passar nos testes em um ambiente de IC antes que as alterações entrem. Eu me oporia a qualquer confirmação diretamente em um desses ramos, embora pareça que o Gitflow por si só não ' Não há problemas em cometer correções ou alterações de pré-lançamento diretamente no ramo de lançamento, puxando-as para o desenvolvimento e depois apresentando ramos.

No seu caso particular, um release-ramo não é um local apropriado. O software já foi liberado e está em master. Depois que um release é mesclado no master e marcado lá, o ramo de release desse release específico sobreviveu ao seu objetivo e não precisa mais existir. Se você é ativo na limpeza de suas filiais (o que eu acho que todo mundo deveria ser), essa nem é uma opção.

Se a sua correção não for crítica, um ramo de hotfix também não parece se encaixar. O objetivo de uma ramificação de hotfix é permitir que alguém faça alterações críticas na produção muito rapidamente, sem interferir no desenvolvimento contínuo. O uso destes deve ser a exceção e não a norma para uma equipe de desenvolvimento. Em geral, os hotfixes críticos devem ser um caso excepcional.

A única coisa que resta é uma ramificação de recursos. Observe que a seção da página vinculada à pergunta sobre ramificações de recursos diz mesmo que as ramificações de recursos são "algumas vezes chamadas de ramificações de tópicos". Se sua alteração está direcionada para qualquer versão futura e não atende aos critérios de um hotfix, ela deve estar em um desses ramos.

— Thomas Owens
fonte

Concordamos que não deve haver compromissos diretos para dominar, desenvolver ou liberar ramificações. Mas qual deve ser o fluxo de PR quando você encontrar um bug na ramificação de lançamento e ele precisar ser corrigido em ambos, liberar e desenvolver ramificações. Isso tem seus próprios desafios se todo o ramo de lançamento ainda não estiver pronto para ser mesclado no desenvolvimento, mas a correção de erros deve ser feita nos dois locais. Se você quiser, posso postar uma nova pergunta para isso.

— Sap

@Sap Uma nova pergunta seria boa, mas se você a publicar, explique por que a correção é tão crítica que precisa ser mesclada em ambas - o que parece implicar que houve um problema crítico não encontrado antes de ser introduzido develop, não encontrado entre o momento em que foi introduzido e a criação do ramo de lançamento e / ou que seu ramo de lançamento existe há muito tempo. Simplesmente, porém, acredito que a única opção é uma seleção de cereja (sugiro uma solicitação de correção e recebimento no ramo de lançamento, mesclagem no ramo de lançamento e desenvolvimento de cereja através de um pedido de recebimento).

— Thomas Owens

Se for um único commit, basta fazer um commit bem identificado e colocá-lo no topo da ramificação de desenvolvimento, caso contrário, crie uma ramificação de recurso.

Também há um comentário do autor do git-flow dizendo exatamente o que você está perguntando: Faltando ramos de correções # 24

— Deb
fonte

Obrigado, esse link que você compartilhou esclareceu isso para mim.

— arcseldon