O Gitflow foi idealizado por Vincent Driessen em 2010 e trata-se de um padrão de gerenciamento de fluxo de trabalho que tem como base o Git. Seu modelo de ramificações possui uma estrutura bem definida, com funções próprias e regras de interação. Na prática, esse rigor garante organização e controle para o gerenciamento de grandes projetos.

Figura 1.1 - Linha do tempo em um projeto com o padrão Gitflow

Ramificações

Para gerenciar o fluxo de trabalho com o Gitflow não é necessário novas tecnologias, conceitos ou comandos, apenas os recursos já disponíveis no Git, como branch (ramo), merge, checkout, tags etc.

O Gitflow possui 5 tipos de ramos, dois deles são considerados principais (master e develop) e os demais secundários ou temporários (release, feature e hotfix/bugfix). Veremos a seguir a definição de cada um deles.

Principais

O ramo master é responsável por manter o histórico de todas as versões de lançamento (produção) do projeto, enquanto o developer, que é derivado do master assim que o repositório é criado, possui o histórico completo do produto. Eles seguiram em paralelo, de forma contínua e nunca serão mesclados diretamente durante toda a vida do projeto, assim, o develop sempre utilizará um ramo secundário (release) para atualizar o master.

O ramo develop reflete o estado mais atual das funcionalidades que estão prontas (desenvolvidas) e foram elegíveis para ir para a próxima release, já o master possui o conteúdo um pouco mais defasado, porém mais seguro para o usuário do sistema.

Figura 1.2 - Destaque para os ramos principais: master e develop

Novos recursos

Para cada nova funcionalidade a ser criada no sistema será gerado um ramo feature próprio a partir da última versão do develop, o ramo mais estável em desenvolvimento. O tempo de vida do novo ramo poderá variar de acordo com o tamanho da nova funcionalidade, porém, após finalizado será mesclado com o develop e excluído em seguida.

Caso seu projeto possua um gerenciador de tarefas, como Jira ou Redmine, é uma boa prática criar os ramos do tipo feature com o nome dos tickets, ex.: feature/<número do ticket>, facilitando a identificação e objetivo do ramo.

Figura 1.3 - Os branches feature só interagem com o develop

Lançamentos

Assim que o ramo develop estiver pronto para um lançamento, seja por acúmulo de novos recursos ou data pré-definida, um ramo release deve ser gerado a partir do develop, dando início a um novo ciclo de lançamento. Por serem consideradas versões "fixas", os ramos de lançamento são isolados em um ambiente de testes e novos recursos não devem ser adicionados a eles, apenas correções de bug, geração de documentação e outras tarefas relacionadas ao lançamento.

Na etapa final de lançamento, o ramo release será mesclado tanto com o master, dando origem a uma nova versão de produção, quanto com o develop, já que correções de bugs e pequenos ajustes foram realizados durante o release. Ao final dos dois merges, o ramo release é excluído.

Figura 1.4 - Fluxo do lançamento de versão

Normalmente os nomes dados aos ramos do tipo release seguem um padrão release/<versão>, com versões incrementais, ex.: 1.0 (major version), 1.0.1 (minor version). O Gitflow também adota a prática de utilizar tags para marcar os releases após irem ao master, então, após fazer o merge de um release para o master, uma Tag com o número da versão pode ser criada para marcar o ponto (commit) do deploy.

Manutenções

Os ramos de manutenção (bugfix e hotfix) são utilizados para corrigir bugs ou problemas críticos que não podem esperar o próximo ciclo de lançamento.

Figura 1.5 - Fluxo do hotfix

• bugfix: se um bug é encontrando durante a etapa de testes no release, é criado um branch bugfix, a correção é feita, ocorre um merge com o ramo release e o ramo de correção é excluído em seguida.
• hotfix: criado ao encontrar um problema crítico que necessita de uma ação imediata no master. Assim, após gerar um ramo hotfix a partir do master e corrigir o problema, serão realizados merges no master, com criação de uma nova tag, e no developer. Ao final, o ramo hotfix é excluído.

A nomenclatura usada para o hotfix e bugfix seguem o seguinte padrão: hotfix/<versão> e bugfix/<versão>, onde <versão> é o valor da nova tag aplicado em master ou release após mesclar o ramo.