GIT-FLOW: UMA ESTRATÉGIA PARA ADAPTAR DE ACORDO COM O PROCESSO DO SEU TIME

💡 O que é o Git-Flow?

Ao trabalhar em equipe, é necessário definir convenções ou boas práticas para que todos saibam trabalhar juntos. O Git-Flow é um dos muitos chamados workflows, bastante popular por sua praticidade e aprendizado relativamente rápido. É uma forma de organizar as branches do seu repositório. Só pegar o Git-Flow e aplica-lo talvez não atenda a necessidade da sua equipe, principalmente pensando na maioria das empresas que possuem setores de Quality Assurance (QA) e esse workflow não leva em consideração.

OBS.: Não irei me atentar em ficar citando os comandos do Git-Flow, o foco neste artigo é outro e você pode consultar esses comandos acessando a Documentação.

⭐ Motivação

Usando essa estratégia, o objetivo é:

• Redução de conflitos, pois o git flow irá ficar responsável por criar e fechar a branch de desenvolvimento no local correto (de forma automática)
• Padronização do nome de branchs, já que o git flow coloca prefixos automáticos como “feature/nome-da-branch” ou “hotfix/nome-da-branch”
• Segurança no processo de desenvolvimento
  • Só sobe o que está OK pelo QA
  • Possibilidade de voltar a produção com base na versão desejada
• Versionamento do sistema através das tags
• Todos os desenvolvedores alinhados com o processo

Organização

Se você pesquisou por "Git Flow" certamente deve ter se deparado com uma imagem parecida com essa:

Essa é a base do Git-Flow e já atende quase todo o fluxo de desenvolvimento, a única adaptação que iremos fazer é inserir o processo de Code Review e o QA que não são contemplados nesse flow.

Adaptação

Então, como já foi dito irei propor um modelo que engloba o Code Review e também os ambientes de teste (QA). A modificação no fluxo fica assim:

Veja que entrou uma nova camada entre as feature e develop. O que significa que antes de ser dado um "finish" na feature, a branch deve passar pelo processo de Code Review e em seguida ir para o QA validar. Se tudo ocorrer bem a ramificação é integrada na develop ao executar:

$ git flow feature finish nome_da_branch

Develop

Outro ponto que podemos observar é que a develop além de ser um "espelho" da "master" em alguns momentos, ela sempre irá conter as features finalizadas (foram testadas pelo QA e validadas).

Segurança

Essas camadas do Git-Flow adicionam mais segurança na subida das novas funcionalidades do seu software, já que para um desenvolvimento chegar em produção (branch master) ele precisa passar pela camada de teste (QA) e em seguida develop. A partir desse ponto é que o desenvolvimento pode ser disponibilizado caso seja criada uma release.

Como aplicar a metodologia a minha equipe ?

O processo pode ser que não se adeque totalmente a realidade do seu time, porém, pode adapta-lo para que chegue em um modelo que atende a necessidade do projeto.

Como dica eu sugiro começar por um repositório e em seguida ir aplicando nos demais (se na sua equipe trabalha em mais de um projeto).

OBS: Processo bom é aquele que resolve o problema do seu trabalho, se a sua equipe já funciona bem com uma metodologia diferente eu não vejo motivos para mudar.

É isso galera, espero ter ajudado vocês falando em uma perspectiva diferente sobre o Git-Flow, pois a maioria dos artigos que vejo são focados no uso da ferramenta (como executar os comandos) e não se atentando a estrutura e organização.