Introdução à estrategias de Branching em projetos.

E ai, tudo beleza? Esse aqui é meu primeiro post de muitos que estão por vir. Assim espero. Se achar algum erro, se tiver alguma dica, qualquer coisa, sinta-se meu amigo de longa data para mandar uma mensagem.

Vamos conversar um pouco sobre fluxos de trabalho em ambientes de desenvolvimento e organização de projetos?

Você já deve ter se perguntado como deveria organizar o fluxo de trabalho e a estrutura de 'branch' no repositório do projeto que está fazendo parte. Pois é, escolher a melhor forma de fazer o 'branching' do projeto pode ser mais complicado do que parece. A forma adotada, pode mudar o modo que entregamos o produto final e todo o caminho até a finalização.
Em projetos de entrega contínua, a forma de trabalhar com o fluxo do projeto é muito importante. Para assim mantermos um controle mais apropriado do que está sendo entregue. Portanto, dentro das possibilidades atuais, temos 3 fluxos que se destacam, são eles: Git Flow; Github Flow e Gitlab Flow.
Git Flow
Idealizado pelo Holandes Vincent Driessen. É um fluxo bem simples e direto para o desenvolvimento de sistemas.
The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.
A 'branch' master é a origem e deve ser vista por todos os usuários do repositório. Paralelamente com a 'branch master' existe uma outra, a 'branch develop'.

Nesse fluxo, é definido que a 'origin/master' a 'branch' principal a qual sempre é a atual versão do projeto. Em 'origin/develop' temos as funcionalidades desenvolvidas que estão consideradas prontas para sair em uma nova versão, o que por muitas vezes é considerado uma 'branch' de integração, já que todas as funcionalidades nesta 'branch' estão sendo construídas. Uma vez que todas as branchs de funcionalidades estiverem prontas, é feito um merge com a 'branch master' e é colocado uma 'tag' de identificação da entrega da versão. Se você trabalha em uma equipe em que existe uma QA bem rígida, definida e possui uma liberação de versão não tão frequente, o Git Flow é ideal para ser usado em sua equipe.

GitHub Flow
O GitHub Flow tem como objetivo ser usado por equipes que façam entregas constantes, times que adotam entrega contínua no desenvolvimento dos sistemas nos quais trabalham. Por trabalhar com entrega contínua, os times que trabalha com esse tipo de fluxo de trabalho devem ser pequenos, com o objetivo de ter uma equipe mais ágil e eficaz.

O GitHub Flow é simples ao ponto de ao iniciar o projeto, faz-se uma nova 'branch' para a funcionalidade a partir da master, ao ter tudo pronto para fazer o 'merge', cria-se um 'pull request' para a master para que alguém revise e aceite a mudança submetida. Evidentemente tudo que está na master é uma versão que deve ser feita o 'deploy' logo após a aceitação do do 'pull request'.
GitLab Flow
Imagine-se em um cenário em que mesmo que tudo esteja pronto para fazer 'deploy', até mesmo que todos os testes tenham passado, contudo ainda existe algum tipo de teste de aceitação da loja de aplicativos, ai que o 'GitLab Flow' entra na jogada. Apenas o que tiver na 'branch' de produção deve ser liberada para o cliente, o que apenas na 'master' já é o suficiente na 'GitHub Flow'.

Para criar um novo 'deploy', podemos fazer o 'merge' com a master em produção. Por causa desse controle, torna-se mais simples para saber a versão por meio da 'branch' de produção e o que está funcionando. Caso tenha algo de errado torna-se mais fácil localizar o problema. Dessa forma torna-se mais fácil para criar uma pipeline automática. O 'GitLab Flow 'cria uma maior confiabilidade no que vai ser entregue, já que para subir até produção, todas as outras 'branchs' devem ser feito um 'merge' com a sua respectiva anterior até chegar na produção, dessa forma garantimos que ao chegar em produção tudo esteja funcionando corretamente.
Então…
Essas estrategias são diferentes e suportam tipos de projetos diferentes. Para projetos em que tenha apenas um desenvolvedor, o 'GitHub Flow' propõem ser mais pratico e ágil para um desenvolvimento solo. Como você trabalha na sua empresa/projeto ? O que melhor serve para seu proposito ? Usa algum outro 'Git WorkFlow' ? Conte me, como você aplica isso…