Git workflows
Visão geral dos Git workflows mais comuns — feature branch, Gitflow, trunk-based e forking — e como escolher o ideal para a sua equipa.
O que é um Git workflow
Um Git workflow é um conjunto de convenções acordadas sobre como uma equipa usa branches, commits e merges para colaborar sem interferir uns com os outros. O Git em si não impõe uma abordagem — fornece as ferramentas, mas não dita como utilizá-las. Um workflow preenche essa lacuna respondendo a perguntas práticas: onde vive o novo trabalho, como é revisto e como chega à produção.
Por que é importante
Sem um workflow partilhado, uma equipa entra rapidamente no caos: trabalho inacabado na branch principal, conflitos de merge inesperados e lançamentos difíceis de reproduzir. Um bom workflow mantém a branch principal pronta para lançamento, torna a revisão uma etapa natural e dá a todos o mesmo modelo mental sobre onde o código está na sua jornada.
O workflow centralizado
O modelo mais simples, e uma boa base para compreender os restantes, é o workflow centralizado: todos fazem commit diretamente numa única branch partilhada (geralmente main). Não existem feature branches — git pull e git push mantêm cada programador sincronizado com o repositório central.
# Get the latest shared history before you start
git pull origin main
# ...make and commit your changes...
git add .
git commit -m "Add user profile page"
# Share your work; rebase on top of any new commits first
git pull --rebase origin main
git push origin mainÉ fácil de compreender, mas escala mal: cada commit vai parar à única branch da qual os colegas dependem, por isso uma alteração inacabada pode quebrar o trabalho de todos. Os workflows abaixo resolvem isso isolando o trabalho em branches primeiro.
Os workflows mais comuns
Estas quatro abordagens baseiam-se na ideia centralizada, mas acrescentam isolamento. Cada uma faz trocas diferentes entre simplicidade e estrutura:
| Workflow | Ideal para | Compromisso |
|---|---|---|
| Feature branch | A maioria das equipas | Simples; o ponto de partida padrão. |
| Gitflow | Lançamentos agendados, produtos versionados | Estruturado, mas mais pesado com muitos tipos de branch. |
| Trunk-based | Entrega contínua, CI robusto | Muito rápido; exige disciplina e feature flags. |
| Forking | Open source, contribuidores não confiáveis | Não requer acesso de escrita; fork extra para gerir. |
Uma feature branch em ação
Na prática, a maioria das equipas começa com feature branches porque os comandos são familiares e o isolamento é imediato. O padrão é sempre o mesmo: criar uma branch a partir de main, fazer o trabalho e depois integrar de volta.
# Create and switch to an isolated branch
git switch -c feature/login
# ...edit files, then stage and commit...
git add .
git commit -m "Add login form"
# Bring the finished work back into main
git switch main
git pull origin main # make sure main is current
git merge feature/login # integrate the feature
git push origin mainA branch mantém main pronta para lançamento enquanto a funcionalidade está incompleta, e dá aos revisores um conjunto autónomo de commits para analisar.
Pull requests em cima de qualquer workflow
Em plataformas como GitHub, GitLab ou Bitbucket, normalmente não se faz merge localmente. Em vez disso, faz-se push da branch e abre-se um pull request (chamado "merge request" no GitLab): um local para rever o diff, executar CI e discutir antes de o código chegar a main.
git switch -c feature/login
# ...commit work...
git push -u origin feature/login # push branch, set upstream
# then open a pull request in the web UIOs pull requests não são um workflow separado — são uma barreira de revisão que pode ser aplicada nos modelos de feature branch, Gitflow, trunk-based ou forking.
Como escolher
Comece com o workflow mais simples que se adapta à sua situação e acrescente estrutura apenas quando sentir a falta dela.
- Uma equipa pequena que lança uma aplicação web continuamente é bem servida pela abordagem de feature branch ou trunk-based.
- Um produto com lançamentos versionados e agendados beneficia das branches explícitas de release e hotfix do Gitflow.
- Um projeto open source que recebe contribuições de desconhecidos necessita do modelo forking, porque os contribuidores não têm acesso de escrita ao repositório principal.
Estes workflows não são mutuamente exclusivos. Muitas equipas combinam ideias — por exemplo, usar feature branches de curta duração com uma mentalidade trunk-based, ou pull requests em cima de qualquer um deles.
O fio condutor comum
Todos os workflows aqui apresentados assentam nas mesmas primitivas que já aprendeu: git branch, git switch, git merge, git rebase e git push. O workflow é apenas uma convenção aplicada por cima desses comandos. Domine os comandos, concorde nas convenções e a colaboração torna-se dramaticamente mais fluida.