Git flow - Evológica

Este conteúdo foi feito para estabelecer um padrão para criação de branchs no gitlab visando uma melhor organização com finalidade de revisão de código.

Criação de branch

Padrão de Versionamento Git-flow

No diagrama abaixo, apresentamos um padrão de versionamento conhecido no mercado como git-flow. Este modelo foi concebido de maneira simples e direta com o intuito de exemplificar o fluxo de trabalho utilizando o git-flow. Vale ressaltar que ele pode ser incrementado com outros pontos do git-flow comumente utilizados no mercado.

Passo a Passo:

1 - Criação de uma Issue no GitLab

É criada uma issue no GitLab dentro do repositório, direcionando uma tarefa ao programador.

2 - Criação de uma Branch a partir da Issue

O programador, por sua vez, cria uma branch a partir da issue/demanda. A imagem abaixo mostra onde realizar a criação da branch a partir da issue, dentro da tela da própria issue.

3 - Criação de Branches para Tarefas Específicas

A partir da branch da issue/demanda, o programador cria uma branch para cada tarefa dentro da sua demanda principal. Exemplo: 542-SEGAUTO-RQ001, 542-SEGAUTO-RQ002, 542-SEGAUTO-RQ003.

4 - Merge Request (MR)

Depois que o desenvolvimento da tarefa é concluído, é feito um Merge Request (MR) da branch da tarefa para a branch da demanda que ele recebeu. Isso facilita a revisão do código, focando apenas na parte que foi alterada. A imagem abaixo é um exemplo de como definir a branch fonte (aquela que você vai criar o MR) e a branch de destino que receberá a solicitação de merge.

Os padrões para um merge request estarão em um tópico dedicado: Padrões de MR (Clique aqui)
Padrões para Merge Request (MR)

Padrões e Sugestões para Títulos e Descrições de Merge Requests

Ao criar um Merge Request (MR) dentro do fluxo git-flow, é crucial seguir padrões e fornecer informações claras para facilitar a revisão e aprovação do código. Aqui estão algumas sugestões:

Título do Merge Request:

O título deve ser conciso e informativo, fornecendo uma visão geral da alteração realizada. Sugestões de padrões incluem:

[Número da Issue] - Descrição Concisa da Tarefa

Exemplo: #542 - Implementação da Feature XYZ

[Tipo de Alteração] - Descrição da Alteração

Exemplo: Feature: Adiciona Autenticação de Usuário

Descrição do Merge Request:

A descrição é uma oportunidade para fornecer detalhes adicionais sobre a alteração. Inclua informações como:

Contexto da Alteração:

Explique por que essa alteração é necessária. Se relaciona a uma issue específica, mencione-a.

Lista de Mudanças:

Enumere as principais alterações realizadas. Isso ajuda os revisores a entenderem as diferenças no código.

Testes Realizados:

Descreva os testes que foram realizados para garantir a integridade da alteração.

Screenshots (se aplicável):

Inclua capturas de tela antes e depois, se a alteração afetar a interface do usuário.

Referências:

Adicione links para documentação relevante, discussões ou referências que possam auxiliar na compreensão da alteração.

Exemplo Prático:

Título do Merge Request:

#542 - Adiciona Funcionalidade de Pesquisa de Usuário

Descrição do Merge Request:

Contexto da Alteração:

Esta alteração atende à Issue #542, que solicitou a implementação de uma barra de pesquisa para facilitar a localização de usuários no sistema.

Lista de Mudanças:

Adição de barra de pesquisa na barra de navegação.

Atualização da lógica de busca no backend.

Testes Realizados:

Testes de unidade para a nova funcionalidade.

Testes de integração para garantir compatibilidade com outras partes do sistema.

Screenshots:

Screenshot da nova barra de pesquisa.

Referências:

Documentação da Issue #542.

Ao seguir essas sugestões, torna-se mais fácil para os revisores entenderem e avaliarem a proposta de alteração apresentada no Merge Request.