Você vai ler sobre:
Ao utilizar o Git para gerenciar versões de um projeto é preciso decidir o fluxo de trabalho (workflow), que irá estabelecer funções bem específicas para diferentes branches e definir quando elas devem interagir. Existem diversos fluxos de trabalhos consolidados e que podem ser utilizados nos projetos. Vale ressaltar que não existe um fluxo de trabalho perfeito onde todos devam seguir, você deve decidir o modelo com base principalmente nas características de implantação do seu projeto. Neste artigo será abordado o fluxo de trabalho chamado Gitflow, criado por Vincent Driessen.
Antes de definir utilizar este modelo em seu projeto é extremamente importante você ter pleno entendimento de quais situações é recomendado o uso do Gitflow. É comum as pessoas acharem que o Gitflow é um padrão que pode ser estabelecido em qualquer projeto que utilize Git, o que não é uma verdade. Você pode ter sérios problemas como limitar a velocidade de entrega e dependências entre features quando este modelo é utilizado em cenários que não são recomendados.
Quando utilizar?
O Gitflow é recomendado e estimulado para projetos que utilizam versionamento semântico (semantic versioning) ou precisam oferecer suporte a várias versões de seu software. Segundo o próprio autor Vincent Driessen, se o projeto exige entrega contínua, como normalmente ocorre em projetos de aplicativos da WEB, este modelo não é recomendado para esse tipo de cenário. Isso porque geralmente na prática, é gerado branches de longa duração que este fluxo favorece. E branches de longa duração atrapalham a entrega contínua, pois é comum gerar os famosos "merge hell" em que exigirá tempo de uma pessoa para resolução de conflitos.
Uma nota foi publicada em 5 de março de 2020 no mesmo artigo em que o autor publicou sobre este modelo. Vale destacar a seguinte parte "...If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team...". O artigo pode ser visualizado em referências / item 2.
Como utilizar?
Branches básicas
O Gitflow inicia com as seguintes branches básicas
- Master: contém o código-fonte de produção já testado
- Develop: contém o código-fonte mais atual incluindo tudo que já foi desenvolvido até o momento (features + hotfix)
https://www.atlassian.com/br/git/tutorials/comparing-workflows/gitflow-workflow
Branches de suporte
A partir das branches básicas são criadas as branches de suporte. As branches de suporte são do tipo feature, hotfix ou release. A imagem abaixo, ilustra a origem para cada tipo de branch e o destino.
- Feature branches são ramos para desenvolvimento de recursos do sistema, criados a partir da branch develop. Após o desenvolvimento retornam para branch develop através de merge.
- Hotfix (correções emergenciais) são branches criadas a partir da master, e o(s) commit(s) são realizados nesse ramo e em seguida deve ser realizado um procedimento de merge em direção a branch master (origem) e develop, para que a correção esteja disponível para as novas features.
- Release branches são utilizadas para preparação do lançamento da próxima versão de produção. São criadas a partir da develop e devem ser mescladas em direção a develop e a master. O merge na develop é importante, pois atualizações críticas podem ter sido adicionadas a release branch e precisam estar acessíveis a novos recursos.
- As branches master e develop são linhas contínuas, ou seja, se mantém durante todo o tempo de projeto.
- As branches de suporte são temporárias, após concluir seu propósito e retornar para a origem devem ser descartadas.
- Não há merge da develop em direção a master diretamente, sempre utiliza-se as release branches.
- As branches que realizam merge em direção a master devem gerar tags.
Praticando
Existem ferramentas para auxiliar no dia a dia quanto a este modelo, você não precisará se preocupar com a origem a qual a nova branch será criada, para onde deve ocorrer o merge quando o trabalho for concluído e se é necessário criar tag. A ferramenta irá gerenciar isso para você. Neste artigo será apresentado uma extensão para linha de comando, como é uma extensão, tal recurso não é instalado nativamente com a instalação do Git. Considere o link abaixo e as orientações para realizar a instalação:
https://github.com/nvie/gitflow/wiki/Installation
Após a instalação:
- Crie um diretório em seu computador com o nome "gitflow";
- Acesse tal pasta utilizando o Git Bash;
- Execute: git flow init;
- Altere os prefixos se preferir ou pressione enter para cada interação para manter o padrão.
Note que se você executar git branch será exibido inicialmente as branches master e develop.
Criando uma feature branch
Para iniciar o desenvolvimento em uma nova feature basta executar o comando abaixo:
git flow feature start <NOME_FEATURE>
Note que denominamos a feature com o nome cache-provider e tal nome foi concatenado com o prefixo definido para este tipo. As ações internas envolveram criar uma nova branch baseada na develop e um checkout em tal branch.
Para demonstração do desenvolvimento da feature hipotética execute os seguintes passos:
- touch cache-provider.js (cria um arquivo em branco chamado cache-provider.js no diretório Git);
- git add cache-provider.js (adiciona o arquivo na área de preparo/staging para o próximo commit);
- git commit -m "adding a cache provider" (realiza um commit que inclui o arquivo recém criado);
- git flow feature finish <NOME_FEATURE> (indica que a feature foi concluída e pode ser "mergeada" para develop).
Como visto na imagem acima, também não é necessário informar o prefixo na hora de encerrar a feature. Ao concluir uma feature as ações internas que ocorrem são: merge da feature em direção a develop, remoção da branch criada feature/cache-provider e checkout na na branch develop. Caso você estivesse desenvolvendo uma nova feature colaborativamente, seria interessante após cada commit você publicar a feature da seguinte forma: git flow feature publish <NOME_FEATURE>
Criando uma hotfix branch
Quando um problema emergencial surge que não se pode esperar a próxima release então pode-se utilizar hotfix. Para isso, basta executar o seguinte comando:
git flow hotfix start <NOME_HOTFIX>
É importante observar que este tipo de branch foi criado baseado na master. Logo após criar a branch é feito um checkout na recém criada branch.
Para demonstração do desenvolvimento da hotfix hipotética execute os seguintes passos:
- touch template-fix.js
- git add template-fix.js
- git commit -m "template bug fix"
- git flow hotfix finish template-fix
Será aberto o editor padrão para solicitar uma definição da tag e do commit de merge. Você deve informar obrigatoriamente ambas as descrições (a descrição do merge já possui uma definição padrão que você pode manter, mas a tag não).
Observe que várias ações aqui foram promovidas: houve um merge da branch hotfix tanto em direção a master como da develop, uma tag foi criada, a branch de hotfix foi deletada e houve um checkout novamente para a branch develop.
Criando uma release branch
A correção emergencial já consta nas duas branches principais, contudo nossa feature ainda não está na master. Para promover a feature na branch master deve-se criar uma release branch. Para isso execute o comando abaixo:
git flow release start <NOME_RELEASE>
Neste momento, foi realizado checkout na branch do tipo release que foi criada a partir da branch develop. Esta branch permite correções antes de ser mesclado na master, o que justifica um merge de volta para develop. Não será realizado nenhum tipo de correção, por isso basta executar:
git flow release finish <NOME_RELEASE>
Note neste momento que um merge foi realizado em direção a master e a develop, uma tag foi criada, a branch release foi deletada e um checkout foi realizado para a branch develop.
Guia
A imagem abaixo ilustra bem como você pode utilizar esta extensão para Gitflow por linha de comando.
https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html
Conclusão:
Este artigo foi abordado de forma teórica e prática com o intuito de gerar uma reflexão quanto a correta utilização do Gitflow e apresentar uma extensão ao Git que auxilia na implementação deste modelo. Como dito, existem diversos fluxos de trabalho e você deve sempre avaliar o contexto de cada projeto para decidir qual fluxo mais se encaixa para cada situação.
Referências
- https://www.atlassian.com/br/git/tutorials/comparing-workflows/gitflow-workflow
- https://nvie.com/posts/a-successful-git-branching-model/
- https://www.luizcorreia.eti.br/gitflow-workflow/
- https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html
- https://jeffkreeftmeijer.com/git-flow/
- https://www.thoughtworks.com/pt/radar/techniques/long-lived-branches-with-gitflow
- https://share.atelie.software/por-que-voc%C3%AA-deveria-diminuir-o-uso-de-branches-c2c07c1ccb07
Sobre o autor
