GIT-FLOW: UMA ESTRATÉGIA PARA ADAPTAR DE ACORDO COM O PROCESSO DO SEU TIME
Tags: git, flow, software, process
Published: 2021-06-16 18:22:40

# :bulb: 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](https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html).

# :star: 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: 
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3xwqxp14q6uvf17xrxuj.png)

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:
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mgnbwi9s5i8s6y4zx0ur.png)
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:
```bash 
$ 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.