Evitando a grade do destino ™ no Git-Flow


8

Meu projeto segue o modelo de ramificação do Git Flow . O desenvolvimento acontece develop, que é mesclado mastere marcado para lançamentos. Os hotfixes acontecem em ramificações ramificadas da corrente master.

No entanto, o desenvolvimento atual também precisa dos hotfixes, para que cada ramo de hotfix também seja mesclado develop.

Isso cria gráficos de revisão muito feios, especialmente os desenvolvimentos / hotfixes são mesclados frequentemente em um curto período de tempo:

Gráfico de revisão feio

Esse é um problema que as pessoas geralmente têm com o Git-Flow e existe uma solução fácil para isso?


2
Com que frequência você está lançando uma nova versão e está usando ramos de hotfix apenas para correções que não podem esperar até a próxima versão agendada?
Bart van Ingen Schenau

@BartvanIngenSchenau pode ser várias vezes ao dia, mas geralmente a cada dois dias. O hotfix ramifica apenas para correções que não podem esperar, sim.
Hannes Struß

4
Por que a estética de um gráfico de revisão é um problema?

1
O rebase não resolve esse problema?
Cuthbert #

1
@Cuthbert, até certo ponto, mas você não pode recuperar o master novamente para desenvolver sem pressionar a força, o que não é uma opção.
Hannes Struß

Respostas:


2

então o seu problema é que você está mesclando cada hot fix duas ou três vezes? (Primeiro a dominar, depois a desenvolver, por fim, de desenvolver a dominar novamente)?

sim, é isso! Não é possível evitar isso, porém, os hotfixes precisam ser mesclados no desenvolvimento

Claro, mas por que mesclar de desenvolver para dominar se nada realmente mudou?

Dê uma olhada em uma dessas master<-develop<-hotfixmesclagens: não deve haver nenhuma alteração real (o hotfix já foi mesclado diretamente ao mestre, afinal). Se não houver mudança, apenas não faça.

De qualquer forma, de acordo com o documento vinculado, as únicas mesclagens de develop para master devem ser feitas através de um ramo de release. Em vez disso, você está mantendo o mestre em sincronia com seu ramo de desenvolvimento (instável) - não.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.