O que é e como funciona o fluxo de trabalho Gitflow?

Este artigo tem o intuito de explicar o que é fluxo de trabalho Gitflow, além de explicar o funcionamento do mesmo em projetos reais.

Caso você já tenha um conhecimento prévio ou já trabalhe com git, com toda a certeza você já deve ter visto diversas abordagens sobre como controlar as versões de projetos, sejam eles pessoais ou empresariais.

É extremamente comum vermos diversos desenvolvedores utilizando uma mesma branch para fazer commits de projetos pessoais para fins de estudo por exemplo. Quando se está trabalhando sozinho, é muito mais simples e prático controlar tudo por meio de uma única branch, porém a situação muda quanto estamos lidando com diversos colaboradores, seja em projetos pessoais, opensource ou em projetos empresariais.

Nesses casos, é necessário um rígido controle para que seja possível identificar o que está sendo produzido pela equipe, onde ao mesmo tempo em que temos falhas sendo corrigidas, temos também novas funcionalidades em desenvolvimento e em implementação. Para isso, é necessário que o código que está em produção esteja com total funcionamento.

E nesses casos em que o gitflow nos auxilia a ter um controle melhor do versionamento do código.

O Gitflow é um modelo alternativo de ramificações ou branchs por assim dizer, onde ele consiste no uso de branchs de recurso e diversas branchs primárias, tendo como diferencial o tempo de vida útil de cada ramificação. Diferente de outros modelos, o gitflow apresenta ramificações com vida longa e commits maiores, onde os desenvolvedores acabam por retardar o merge até que o recurso que está em desenvolvimento na ramificação trabalhada seja concluído.

Como o tempo de vida útil dessas ramificações de recurso acaba sendo muito longo, é necessário um esforço maior para realizar o merge devido ao risco da branch trabalhada acabar introduzindo atualizações incorretas e gerar o famigerado “conflito”.

Vale ressaltar que o Gitflow pode ser utilizado para projetos que possuem um ciclo de lançamento agendado, além de também ser utilizados juntamente com a prática da cultura DevOps de entrega contínua. Lembrando que o gitflow não adiciona novos conceitos nas ramificações trabalhadas, mas sim atribui funções bem específicas para diversas ramificações e define quando elas devem interagir.

Conforme a imagem acima, podemos ter uma base sobre o funcionamento o fluxo gitflow, onde a branch ou ramificação master irá armazenar todo o código que já se encontra testado e homologado e que será entregue ao cliente, enquanto a branch develop é onde irá ocorrer todo o fluxo de trabalho antes do merge junto a branch master.Uma ressalva importante é que nesse fluxo, a branch develop sempre irá conter a versão mais atual do código.

Como a branch develop sempre irá conter a versão mais atual, as futuras ramificações ou branchs features serão ramificadas tendo a develop como base.

Um ponto importante é que o gitflow sugere um padrão de nomenclatura para as ramificações, sendo ele:

• master: código testado e homologado e entregue ao cliente;
• develop: código mais atual e onde o fluxo de trabalho ocorre;

• feature: novos implementações;
• release: responsável por finalizar release de tag;
• hotfix: responsável por resolver bugs críticos em produção que não podem esperar que seja lançado um novo release. Salvo a exceções, a branch hotfix é a única que deve ser gerada a partir da branch master.

Pois bem, vamos criar um exemplo onde podemos ver o gitflow em prática.

Temos aqui nosso repositório “Jogos” onde nesse momento temos apenas uma única branch, sendo ela a master. Iremos agora criar a branch develop e iniciar o nosso fluxo de trabalho.

Para isso, iremos digitar o seguinte comando:

git checkout -b develop

Agora estamos na branch develop onde irá ocorrer nosso fluxo de trabalho e onde o código mais atual ficará. Para novas implementações, agora podemos gerar a partir da branch develop, as nossas features e trabalhar nelas separadamente sem impactar nosso código que já se encontra em produção e sem impactar o nosso código mais atual e estável.

Para gerarmos nossa branch feature, basta digitarmos o seguinte comado:

git checkout -b feature/nova-funcionalidade.

Lembrando que precisamos gerar essa branch a partir da develop.

Caso seja necessário que outra pessoa trabalhe nessa funcionalidade, você deve compartilhar suas alterações com o repositório remoto.

Para isso, você deve “subir” suas alterações utilizando o comando:

 git push origin feature/nova-funcionalidade.

Agora que a implementação foi feita, podemos fazer o merge junto a branch develop. Para isso, é necessário voltarmos para a branch develop, realizar o merge da feature e atualizar nossa branch remota.

git checkout develop && git merge feature/nova-funcionalidade && git push origin develop

Caso não ocorra nenhum conflito nessas etapas, podemos criar nossa branch release referente a nossa implementação.

Para isso, basta criarmos a branch partir da branch develop e submeter a mesma para nosso repositório:

git checkout -b release/v1Nova-Funcionalidade && git push origin release/v1Nova-Funcionalidade

Caso seja identificado algum bug nesta etapa, devemos corrigi-lo na branch release e depois enviar os ajustes tanto para a branch develop quanto para a branch master. Podemos agora criar nossa tag referente a branch release em questão.

git tag -a nova-funcionalidade -m “Release de nova Funcionalidade”

Caso tudo tenha ocorrido sem problemas, já estamos aptos a realizar o merge da tag junto a master.

git checkout master && git merge release/nova-funcionalidade

Em alguns casos, você irá se deparar com merges sendo realizados entre as branchs develop e master, sem a necessidade da release conforme abaixo:

git checkout master && git merge develop

Com os processos realizados, temos um rígido controle a respeito da versão de nosso código, além de sabermos exatamente o que está sendo desenvolvido, tudo sem impactar o processo que já encontra-se em produção.

Sendo assim, nem sempre será necessário que você imponha todas as regras e condições determinadas pela estrutura gitflow em seu projeto, porém é muito importante adotar as partes mais importantes do fluxo e utilizá-las durante o desenvolvimento, como por exemplo a criação de novas funcionalidades em paralelo com a solução de bugs que podem ser adaptados e adequados de acordo com a estrutura de trabalho adotada, de maneira com que o fluxo seja otimizado e o risco de possíveis conflitos seja drasticamente reduzido.

Por fim, se você gostou do artigo, por favor, deixe um comentário e compartilhe para que mais pessoas possam ver o conteúdo. Lembre-se de acompanhar a Konia nas redes sociais. Um abraço e até a próxima!