Gitflow - Melhores práticas com o Git (com e sem extensão)

Começando do começo

Sabemos que para trabalhar como desenvolvedor é de grande importância ter conhecimento sobre Git. Muitos desenvolvedores quando estão começando suas carreiras não dão a devida importância a essa ferramenta de versionamento de código, se você ainda não sabe o que é o Git e como ele funciona eu sugiro que leia um pouco sobre isso aqui: O que é Git.

Mas o que seria o Gitflow? O Gitflow, seguindo a definição da Atlassian, é uma ideia abstrata do fluxo de trabalho Git, ou seja, ele dita que tipos de ramificações configurar e como fazer o merge, podemos pensar no Gitflow como uma metodologia que vem para ajudar a resolver problemas de organização.

Como funciona?

Vamos abordar nesse conteúdo os procedimentos com e sem a extensão do Gitflow, caso você queira instalar essa extensão na sua máquina aqui está o Link: Instalando Gitflow

No Gitflow trabalhamos com duas branchs principais, elas são a branch Main e a Branch Develop, na branch Main nós armazenamos o histórico do lançamento oficial, de forma mais intuitiva, podemos considerar que na branch Main nós temos aquilo que está em produção, já a branch Develop é uma ramificação que usamos para desenvolver novas features e integrar novos recursos.

Para seguirmos essa prática nós criamos uma branch Develop no nosso repositório git e fazemos o push dela para nosso repositório no GitHub:

git branch develop
git push -u origin develop

Para fazermos o mesmo procedimento usando a extensão do Gitflow nós precisamos apenas usar um git flow init e então seguir os padrões oferecidos pela própria extensão, recomendo apenas que altere o nome da branch de Master para Main, ao final você poderá mudar da branch Main para a Develop.

$ git flow init

Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

$ git branch
* develop
 main

Após fazemos esse procedimento é interessante que nós mudemos nossa branch principal no nosso GitHub também para nossa branch Develop, fazemos isso indo no nosso repositório do GitHub, na opção settings e em seguinda escolhemos a opção "default branch"

Agora basta apertar no botão de "switch" e alterar sua branch padrão para a branch Develop.

Criando Features

Sempre que desenvolvemos uma nova feature ela deve ser desenvolvida em uma branch própria e só depois de desenvolvida fazemos um Pull Request dessa branch ou um merge direto dessa branch na nossa branch Develop.

Vamos supor que você queira desenvolver uma feature de login, o fluxo de trabalho seria esse:

Criariamos uma nova branch para essa feature seguindo o padrão "feature/nome_da_feature"

git checkout -b feature/login

Com a extensão do Gitflow:

git flow feature start feature/login

A partir daqui desenvolveriamos nossa feature usando o git como de costume. Finalizando nossa feature temos algumas opções, podemos fazer um merge dessa feature direto na nossa branch Develop

git checkout develop
git merge feature/login

Com a extensão do Gitflow:

git flow feature finish feature/login

Ou podemos trabalhar com Pull Request (que é a forma que prefiro trabalhar, utilizando CI e também status check)

git push origin feature/login

Após fazer isso você vai notar uma notificação no seu repositório sugerindo um Pull Request

Basta clicar em "compare & pull request" e fazer o merge da sua branch

depois do merge o Github te pergunta se você deseja deletar a branch, clique para deletar a branch

Após deletar a branch é importante voltar no seu Git e seguir os seguintes passos:

git checkout develop
git pull origin develop
git branch -d feature/login

Com isso nós coletamos todas as mudanças feitas e deletamos nossa branch feature/login.

Release de lançamento

Quando nossa branch Develop já possui recursos o suficiente para ir ao ar é hora de criarmos uma ramificação dessa branch como uma release, na nossa branch de release nenhum novo recurso deve ser adicionado, nós usamos ela para fazermos testes, atualizações de segurança, documentação e etc

Essa branch é importante pois garante ainda mais que nenhum bug avance para a produção, além disso é muito interessante ter uma branch de release, pois enquanto ela está sendo preparada para lançamento outra equipe pode continuar com o desenvolvimento de novas features na branch Develop.

É importante saber que essa ramificação é marcada com o número da versão que vai ser lançada, o fluxo de trabalho seria esse:

git checkout develop
git checkout -b release/0.0.1

Com a extensão do Gitflow:

git flow release start 0.0.1

Depois disso fazemos o merge da release na nossa branch Main e na nossa branch Develop e deletamos a branch de release:

git checkout main
git merge release/0.0.1
git checkout develop
git merge release/0.0.1
git branch -d realease/0.0.1

Com a extensão do Gitflow:

git flow release finish '0.0.1'

Ramificação para correção de Bugs em produção

No Gitflow temos as ramificações usadas para correção de bugs ou manutenções, elas são chamadas de Hotfix, elas são usadas para fazer correções rápidas em produção e são as únicas branchs que devem ser bifurcadas direto da branch Main.

O fluxo de trabalho seria esse:

git checkout main
git checkout -b hotfix/nome_da_correção

Com a extensão do Gitflow:

git flow hotfix start nome_da_correção

Assim como na finalização de uma Release nós fazemos o merge desta branch tanto na branch Main quanto na branch Develop e depois deletamos a branch de hotfix:

git checkout main
git merge hotfix/nome_da_correção
git checkout develop
git merge hotfix/nome_da_correção
git branch -D hotfix/nome_da_correção

Com a extensão do Gitflow:

git flow hotfix finish nome_da_correção

Precisamos lembrar que o Gitflow é uma metodologia, isso não quer dizer que ele seja de uso obrigatório ou que você nunca possa usar o Git de uma forma diferente, eu particularmente gosto de usar ele nos meus projetos, mas quando você estiver trabalhando em time é sempre bom discutir com seus colegas como será a padronização do trabalho com o Git e Github.

Espero ter ajudado um pouco no aprendizado e estudo de todos que leram.