Qual é a convenção de nomenclatura / processo correta com o GitFlow para criar um sub-ramo de uma ramificação de recurso?

5

Estou usando o GitFlow para minhas convenções de desenvolvimento. De um modo geral, eu crio uma história de usuário e um recurso de correspondência ramificam meu ramo de desenvolvimento e trabalham nisso. Quando a história estiver completa, o recurso será concluído e mesclado (realocado) de volta ao desenvolvimento.

No entanto, estou correndo para o problema em que meu recurso é mais épico. Há uma quantidade significativa de desenvolvimento que será necessária antes que o recurso (épico) possa ser entregue (ele deve ser entregue como uma única entrega). Mas trabalhar apenas em um ramo de recursos não é apropriado.

Dito isto, qual é a convenção apropriada para fazer algo assim? Eu crio meu branch épico chamado feature / MyEpicName e depois digo a todos os meus desenvolvedores para usar feature / MyEpicName como sua ramificação "develop" equivalente? Eles então criariam todos os seus ramos de recursos baseados naquele ramo e mesclariam as alterações de volta a esse ramo.

No entanto, se eu seguir um processo como esse, minha convenção de nomenclatura começa a ficar complicada. Normalmente (por convenção), feature / xxxx implica um branch de feature do branch de desenvolvimento. Se meus desenvolvedores usarem o recurso / MyEpicName como sua ramificação "desenvolver", eles ainda criarão seu próprio recurso / ramificação. Mas então se torna uma bagunça gigantesca para tentar entender qual característica é ramificada de desenvolver e qual é ramificada a partir do épico.

Existe uma convenção / processo de nomenclatura aceitável para lidar com esse tipo de situação? Eles chamam seu recurso de ramificações de recurso / MyEpicName / xxxxyyyy?

O último irá quebrar algumas das ferramentas / scripts? Ex: ganchos de gitflow, smartgit, etc.

    
por Eric B. 24.11.2016 / 17:11
fonte

2 respostas

4

Para ramos de recurso, usamos a convenção de nome-recurso / recurso. Por exemplo, reescrever aspas / recurso como o ramo de recurso principal. O recurso de palavra-chave aqui é uma convenção usada para sinalizá-lo como o principal recurso.

As sub-ramificações serão nomeadas como nome do recurso / nome da sub-ramificação. Por exemplo, reescrever-citar / citar o modelo

A vantagem disso é fácil de ver onde cada ramo pertence. Algumas ferramentas irão agrupá-las em uma visualização semelhante a uma pasta (sourcetree)

    
por 24.11.2016 / 17:55
fonte
2

Não há convenção para isso. Talvez porque os ramos de longa duração sejam vistos como Bad Thing (tm)

Se esse épico é a próxima versão do software, o ramo de desenvolvimento é o lugar certo para ele. seus 'sub-recursos' são ramificações de recursos, que você cria da maneira usual e, em seguida, quando todos estiverem prontos, você mescla o desenvolvimento em mestre e faz um lançamento.

Se você tiver resultados que entrem em ação ANTES da conclusão do seu épico, você seria forçado a mesclá-los de volta ao seu ramo épico, atrasando assim o seu progresso enquanto você integrava as alterações, retestado etc.

Eu não acredito que haja uma solução para essa situação. Você pode usar a função de recurso para desativar os recursos inacabados e, em seguida, ativá-los quando a epopéia terminar. Mas isso não é ideal, pois você terá um trabalho inacabado no mestre.

A melhor abordagem na minha opinião é reavaliar o épico e dividi-lo em resultados menores que você pode completar no seu ciclo de lançamento normal.

Por exemplo, você poderia atualizar o banco de dados com novas tabelas, mesmo que a camada api não as use ainda? então a camada api, embora não seja usada pelo frontend, etc etc

    
por 24.11.2016 / 17:40
fonte

Tags