📝 GitFlow na Prática: Guia Definitivo para o Controle de Versão em Ambientes Profissionais

Você já passou pela frustração de ter uma funcionalidade incompleta indo para produção, ou de ter que fazer um hotfix urgente e acabar quebrando o que a equipe ainda estava desenvolvendo? Em um ambiente de desenvolvimento profissional, a forma como organizamos nosso histórico de código é tão importante quanto o código que escrevemos. É aqui que entra o GitFlow. Mais do que uma simples lista de comandos, o GitFlow é uma metodologia estruturada que nos permite separar o que é desenvolvimento, o que está em teste e o que é o ‘puro sangue’ da nossa aplicação em produção. Neste artigo, vamos explorar como implementar esse fluxo passo a passo para trazer previsibilidade e segurança às entregas da sua equipe.

No GitFlow (Tradicional), o foco é a organização e a separação clara de responsabilidades entre ambientes. Ele é ideal para equipes que precisam de um controle rígido sobre o que é liberado e quando.

Diferente do Trunk-Based, aqui o Git é a ferramenta de controle de liberação. O segredo do GitFlow é que cada branch de longa duração tem uma função específica.

A Hierarquia do GitFlow Link para o cabeçalho

Para este cenário, você terá sempre duas branches “imortais”:

1. main (ou master): Reflete exatamente o que está em produção. Nunca se faz commit aqui, apenas merges de release ou hotfix.

2. develop: Onde o código integrado vive. É a base para as novas funcionalidades.

O Fluxo Passo a Passo (Esteira de Produção) Link para o cabeçalho

1. Início de uma nova Feature Link para o cabeçalho

Você cria uma branch a partir da develop:

git checkout -b feature/novo-checkout develop

• Você faz seu trabalho aqui. Quando termina, abre um Pull Request para a develop.

• Após aprovado, o código entra na develop.

2. Preparação para o Release (Staging) Link para o cabeçalho

Quando a develop já tem tudo o que você quer colocar na próxima atualização (ex: versões 1.1.0), você cria uma branch de release:

git checkout -b release/v1.1.0

• Este é o seu momento de Staging: O seu pipeline de CI/CD deve ser configurado para ler esta branch release/v1.1.0 e fazer o deploy automático no seu ambiente de Staging.

• Ajustes finais: Se encontrar um bug, você corrige na própria branch de release.

3. O “Deploy” de fato (Produção) Link para o cabeçalho

Quando o teste no Staging está aprovado, você move a versão para a main:

1. Faz o merge da release na main.

2. Cria uma Tag na main (ex: v1.1.0) para marcar aquele momento histórico.

3. Sincronização: Faz o merge da release (ou da main) de volta para a develop, para garantir que qualquer correção feita na fase de testes do release não se perca.

4. O que fazer em caso de Bug em Produção? (Hotfix) Link para o cabeçalho

Se algo quebrou em produção e você não pode esperar o ciclo da develop:

1. Crie uma branch de hotfix a partir da main: git checkout -b hotfix/bug-urgente.

2. Corrija o bug.

3. Faça o merge da hotfix na main`` (e crie a tag de correção, ex: v1.1.1).

4. Crucial: Faça o merge da hotfix na develop também, para que o erro não volte a aparecer no próximo release.

Resumo da Esteira para Equipe Pequena Link para o cabeçalho

Por que usar o GitFlow se é mais trabalhoso? Link para o cabeçalho

1. Isolamento total: Você pode ter uma versão 1.0 rodando em produção enquanto prepara a 1.1 no release, e a equipe continua trabalhando na 1.2 na develop.

2. Histórico limpo: A main só tem o histórico de “versões oficiais”. É muito fácil voltar atrás (rollback) se algo der errado, pois basta apontar a main para uma tag anterior.

3. Segurança: Se o seu cliente exige aprovação humana antes de qualquer atualização, o GitFlow facilita isso: o merge na main só ocorre após o “ok” no release.

Dica de Ouro para o GitFlow Link para o cabeçalho

Não tente fazer cherry-pick entre main, develop e release constantemente. Siga o fluxo de merges. Se você seguir a regra de sempre mesclar a hotfix ou release **de volta para a develop, você nunca terá problemas de código perdido.