# Como fazemos o Gitflow

Já falamos por aqui sobre [como trabalhar com Git](https://devgo.com.br/como-trabalhar-com-git), mas ter um bom fluxo de branchs e features no seu Git, que garanta uma entrega ágil e segura para a sua equipe, pode ser um pouco mais complicado do que parece. No artigo de hoje, vamos contar como gerenciamos o Git por aqui na [Devnology](https://devnology.com.br/).

## Dificuldades de um bom fluxo no Git

Algo bem popular no gerenciamento de projetos no Git é ter as conhecidas branchs `develop` para um ambiente de desenvolvimento,`homolog` para um ambiente de testes e finalmente `main` para o ambiente de produção do nosso projeto. Um modelo bastante comum de Git Flow é a cada nova demanda uma branch `feature` é criada, e finalizado é feito um merge para a branch de desenvolvimento. Terminada o processo de desenvolvimento, com a branch `develop`  é feito um merge para a branch `homolog` para os testes. Concluído os testes, a branch `main` é atualizada com a branch `homolog`. Assim vemos um fluxo muito claro de `feature` → `develop` → `homolog` → `main`. 

Este processo faz bastante sentido em um momento inicial quando o seu projeto ainda está em desenvolvimento e não foi lançado em produção, mas a partir do momento em que o projeto está no ar, pessoas estão utilizando e novas melhorias continuam sendo feitas, este fluxo pode dificultar bastante a sua entrega.

Vamos imaginar um momento em que seu projeto está no ar, e há 3 novas melhorias sendo desenvolvidas. As 3 novas melhorias, nas branchs `feature1`, `feature2` e `feature3`  passaram pelo `develop` e foram para a branch `homolog` para que o processo de teste se inicie. Durante os testes a melhoria 1 e a melhoria 3 foram aprovadas, mas a melhoria 2 precisou de ser feito um ajuste e a branch `feature2` voltou para o início do processo. Agora, você tem a `feature1` e `feature3` aprovadas em `homolog` prontas para subir em produção, mas seguindo este fluxo comum, em que você não pode fazer uma atualização `homolog` → `main` porque a branch `homolog` está “suja”, pois também contem a `feature2` que ainda não foi aprovada. Você deverá parar todo seu processo de entrega, e esperar que seja retestado e aprovada para fazer um novo release em produção.

![1.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1661518640359/SCsFspID0.png align="center")

Se você quer agilidade na sua entrega esse modelo não é suficiente. Pense que se a melhoria 1 e a melhoria 3 estão prontas, você já deveria poder atualizá-las em produção. Já pensou se esse ajuste que será feito na melhoria 2 é mais complexo do que parece, e demore mais de 1 mês?

## Um modelo de estratégia para agilidade na entrega

Para melhorar a nossa entrega, focamos em um modelo de “independência” entre as branchs. Nessa nova estratégia, quebramos as relações entre os de ambiente de desenvolvimento `develop`, `homolog` e `main`. Essas branchs não entram mais uma em contato com a outra, e o fluxo `develop` → `homolog` → `main` não existe mais. Cada branch de melhoria sobe independente uma da outra, em um fluxo como: `feature`→ `develop` , depois `feature` → `homolog` e por fim `feature` → `main`.

![2.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1661518650618/oRgbrNzxy.png align="center")

Voltando ao nosso exemplo de 3 melhorias sendo desenvolvidas paralelamente, em que as 3 melhorias estão em teste no ambiente `homolog`, mas apenas as melhorias 1 e 3 foram aprovadas: podemos fazer `feature1` → `main` e `feature3`→ `main` imediatamente, sem aguardar para que a `feature2` seja ajustada.

## Possíveis problemas e como contornar

Nossa grande preocupação neste fluxo é manter a branch “limpa”, ou seja, a branch `feature` conter apenas a melhoria onde ela se refere.

Com tudo ocorrendo bem, isso acontece naturalmente: não misturamos as branchs `feature` e elas sobem uma de cada vez para cada ambiente. Mas ainda pode ocorrer um conflito —quando as mesmas branchs mexem no mesmo arquivo. 

Em exemplo: foi feito um merge para a branch `feature1` em `homolog`. Algum tempo depois, foi também feito um merge para a branch `feature2` em `homolog`. Neste momento foi entregue um alerta de conflito. Para resolver um conflito, basta que a `feature2` fosse atualizada com a branch `homolog` e o conflito resolvido internamente, mas perceba que se fizer isso a branch `feature2` irá também conter a branch `feature1`, pois ela estava em `homolog` naquele momento. Isso faz com que sua branch `feature2` fique suja e pode ser um grande problema. Caso ocorra uma situação como em nossos exemplos, de que a `feature2` seja aprovada, mas a `feature1` ainda precise de ajustes, você não poderia mais subir a `feature2` em produção, pois ela irá acabar levando em conjunto a `feature1`. 

Este não é um problema impossível de ser resolvido. Basta duplicar, criando uma branch secundária, com base na `feature2` apenas para a resolução de conflito, algo como `feature2-homolog`. Use essa nova branch para resolver o conflito, e realize o merge de `feature2-homolog` para `homolog`. Com isso, a `feature2` continua limpa e pode ser realizado um merge para a `main` sem mais preocupações —perceba até que `feature2-homolog` foi usada em apenas um único momento.

E se a melhoria 2 precisar de um ajuste? Resolva o ajuste naturalmente na branch `feature2`. Continue com o fluxo normalmente, envie-a para `develop` e ao chegar em `homolog`, onde ocorreu um conflito anteriormente, atualize a sua branch `feature2-homolog` com o ajuste, e continue usando essa branch para resolução de conflito.

![3.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1661518688192/KzaIqxri2.png align="center")

Perceba que nosso grande problema são em casos de conflitos. Uma boa dica é criar uma rotina de atualização das branchs `develop` e `homolog`. Essas branchs devem sempre ser independentes, mas não é bom que elas se percam no fluxo e acabem sempre por indicar conflitos. Confira estes ambientes de tempo em tempo e os deixem sempre atualizados com a `main`. 

## Como se adaptar a este fluxo

Na prática, este fluxo “ágil” funciona bastante bem e podemos ver resultados rapidamente após sua implementação. Para uma boa implementação deste fluxo é preciso uma mudança na mentalidade e comprometimento da equipe. Tudo deve ser feito com bastante cuidado para evitar problemas, mas a partir do momento que as ideias se encaixam tudo passa a fluir naturalmente.

Lembre-se sempre de criar suas branchs com base na `main` e siga o fluxo com bastante calma, uma vez para `develop`, outra para `homolog` e finalmente para a `main`. Jamais resolva conflitos diretamente na branch `feature` e tudo ocorrerá bem.

Devo dizer também que nenhum fluxo ou metodologia é uma “lei”. Para uma real boa adaptação é importante que pensar na sua equipe, no projeto e principalmente na experiência em que foi construída ao redor destes dois pontos. Traga os métodos e conhecimentos que você tem estudado para a sua própria realidade.

Nos próximos projetos da devGo tentaremos levar este fluxo a prática durante a etapa de desenvolvimento. Acompanhe nosso [canal no Discord](https://discord.gg/H5wPNCTRwq), inscreva-se em nossa newsletter e acompanhe os nossos conteúdos de perto.