Fluxos de trabalho no Git (Gitflow, GitHub Flow, outros)

Introdução

Um fluxo de trabalho no Git descreve como usar o git para gerenciar as versões de um projeto. Definir um fluxo de trabalho facilita a organização do projeto, o desenvolvimento em equipe, e a implementação e teste de novas features. Neste artigo exploraremos brevemente alguns fluxos de trabalho no Git que são amplamente usados para garantir um processo de desenvolvimento organizado e eficiente.

Gitflow

O Gitflow é um dos fluxos de trabalho mais conhecidos, ideal para projetos que possuem ciclos de desenvolvimento bem definidos, como releases. Ele organiza o trabalho em duas branches principais: main e develop. Além disso, utiliza branches adicionais para features, releases e hotfixes.

Em resumo, a ideia dessa estratégia de trabalho é que a branch main vai conter o código que está em produção e a branch develop vai conter o código que ainda está em desenvolvimento. As outras branches tem duração finita e servem como suporte para essas duas principais.

A branch de features deve sempre sair da branch develop e contém novas funcionalidades que estão sendo implementadas. Quando a funcionalidade estiver pronta essa branch deve ser mergeada novamente na branch develop.

A branch de releases é uma ramificação da branch develop e serve para preparar uma nova release! A ideia é fazer os últimos ajustes antes de mergear na branch main como um novo lançamento.

E por fim, a branch hotfixes também é uma ramificação da branch de develop e também deve ser mergeada na branch main, mas dessa vez com ajustes importantes e urgentes que não podem esperar uma nova release.

Esse workflow é muito útil pois facilita o gerenciamento de releases e hotfixes e permite testes robustos antes de integrar mudanças na produção - através da branch de releases. Por outro lado, o próprio autor do blog post original que introduziu esse modelo destaca que esse pode não ser o melhor fluxo para projetos que tem deploy contínuo, como sites que estão sujeitos a alterações constantes.

Github Flow

O GitHub Flow é um fluxo de trabalho mais simples, ideal para projetos iterativos (como projetos com Deploy contínuo) ou para equipes que lançam atualizações frequentes. Ele utiliza uma única branch principal (main) e todas as mudanças são feitas por meio de pull requests.

A ideia é que cada nova feature seja desenvolvida numa branch separada da main, mas que é mergeada de novo diretamente na main, ou seja, sem uma branch de desenvolvimento. Antes de fazer o merge os desenvolvedores abrem um "pull request", um pedido para fazer o merge. Nessa hora, outros desenvolvedores revisam as mudanças e decidem se aprovam ou não ou ainda se fazem algumas mudanças. Depois do merge a branch com a feature pode ser excluída.

Para que isso funcione bem, os commits tem que ser feitos com alterações específicas, o que facilita a revisão e a correção caso necessário. Além disso, antes de fazer o merge de uma feature na main, é fundamental que a equipe faça uma revisão atenta para evitar que erros sejam integrados em produção.

Esse fluxo de trabalho tem a vantagem de ser mais simples e menos "burocrático". Por outro lado, pode não ser o ideal para projetos que tem releases bem definidas.

Outros Fluxos

Fluxo de trabalho centralizado

Neste fluxo, há uma única branch principal (main ou trunk) onde todas as mudanças são integradas. O foco está em commits pequenos e frequentes. A integração contínua e bons testes são essenciais para garantir que o código esteja sempre em um estado utilizável.

Esse método é simples de aplicar e não tem problemas com conflitos entre branchs, porém corre o risco de introduzir erros no código em produção.

Forking Workflow

O Forking Workflow é amplamente utilizado em projetos de código aberto e para colaboração entre equipes distribuídas. Nesse fluxo, cada desenvolvedor cria um fork do repositório principal, fazendo suas mudanças em seu próprio repositório antes de enviá-las de volta ao repositório original via pull request. É similar ao github flow, mas com a diferença que cada desenvolvedor tem um fork do projeto, isto é, uma cópida de uma versão do projeto. Isso faz com que os desenvolvedores não precisem de permissão para fazer edições no repositório, tornando esse fluxos excelente para projetos open source.

Conclusão

Existem muitos outros fluxos de trabalho possíveis e cada um tem suas vantagens e desvantagens. É importante lembrar que nenhum método é perfeito para todos os cenários e natural fazer adaptações