Workflow de branch de funcionalidade

Visão geral

O workflow de feature branch é a forma mais comum de equipes colaborarem com Git. A regra é simples: todo o desenvolvimento ocorre em branches dedicadas, nunca diretamente no main. Cada nova funcionalidade, correção ou experimento recebe sua própria branch, e a branch main só recebe trabalho concluído e revisado. Isso mantém a main estável e pronta para deploy em todos os momentos.

A ideia central

Como o trabalho fica isolado em branches, várias pessoas podem desenvolver funcionalidades diferentes em paralelo sem interferir umas nas outras. A main atua como a única fonte de verdade para o código pronto para produção. Uma branch é uma unidade de trabalho focada que tem um início claro (criada a partir da main) e um fim claro (mesclada de volta na main).

É importante destacar que uma branch no Git é barata: ela é apenas um ponteiro móvel para um commit, não uma cópia dos seus arquivos. Criar uma branch é instantâneo e usa quase nenhum espaço em disco, o que é exatamente por que criar uma branch por tarefa é prático.

Nomeando branches

Um esquema de nomenclatura consistente torna as branches autodocumentadas. A maioria das equipes usa um prefixo com o tipo e uma referência à tarefa em andamento:

feature/login-form
feature/W3-142-checkout-page
fix/null-pointer-on-logout
chore/upgrade-eslint

A barra é apenas uma convenção — o Git trata feature/login-form como um único nome de branch, embora permita que ferramentas agrupem branches por prefixo. Evite espaços e letras maiúsculas para manter os nomes fáceis de digitar.

Um exemplo passo a passo

O workflow é um ciclo curto e repetível: crie uma branch a partir da main, trabalhe, faça push, revise, mescle e limpe.

1. Crie a branch a partir de uma main atualizada

Sempre comece a partir da main mais recente para que sua branch seja baseada no código atual:

git switch main
git pull
git switch -c feature/login-form

git switch -c cria a branch e faz o checkout em um único passo (o equivalente antigo é git checkout -b). Veja git switch para o comando completo.

2. Faça o trabalho, fazendo commits ao longo do caminho

Faça commits em etapas pequenas e lógicas, em vez de um único commit gigante no final — commits pequenos são mais fáceis de revisar e de desfazer:

git add login.html login.js
git commit -m "Add login form markup and validation"

Prefira fazer o staging de arquivos específicos em vez de git add . para não enviar acidentalmente mudanças não relacionadas. Leia mais sobre como criar bons commits em git commit.

3. Faça push da branch

Faça push para que seus colegas possam ver seu trabalho e para que você possa abrir um pull request. O flag -u vincula sua branch local à remota, para que depois você possa simplesmente digitar git push:

git push -u origin feature/login-form

Veja git push para entender em detalhes o que -u (--set-upstream) faz.

Revisão e mesclagem

Em uma plataforma de hospedagem como GitHub ou GitLab, você abre um pull request (PR), chamado de merge request no GitLab. É onde os colegas revisam o diff, deixam comentários e aprovam. As verificações de integração contínua (CI) geralmente executam o conjunto de testes contra a branch automaticamente. Após a aprovação do PR e os checks estarem verdes, a branch é mesclada no main.

Há três estratégias de mesclagem comuns oferecidas por essas plataformas:

• Merge commit — preserva todos os commits da branch mais um commit de mesclagem. Mantém o histórico completo, mas pode gerar ruído.
• Squash and merge — reúne todos os commits da branch em um único commit organizado no main. Popular porque o main fica limpo e cada funcionalidade é uma entrada única.
• Rebase and merge — reproduz os commits da branch no main sem commit de mesclagem, resultando em um histórico linear.

Limpe após a mesclagem

Após a branch ser mesclada, exclua-a localmente e remotamente para que o repositório não fique cheio de branches obsoletas:

git switch main
git pull
git branch -d feature/login-form        # delete the local branch
git push origin --delete feature/login-form   # delete the remote branch

git branch -d recusa excluir uma branch que não foi mesclada, o que protege você de perder trabalho. (Use -D para forçar a exclusão quando tiver certeza.)

Mantendo uma branch atualizada

Se a main avançar enquanto você trabalha, traga essas mudanças para sua branch para que a mesclagem final seja tranquila e os conflitos apareçam cedo. Você tem duas opções:

# Option A — merge main into your branch (keeps history as-is)
git switch feature/login-form
git merge main

# Option B — rebase your branch onto the latest main (linear history)
git switch feature/login-form
git rebase main

Mesclar não é destrutivo e é seguro para branches compartilhadas, mas adiciona commits de mesclagem. Fazer rebase produz um histórico mais limpo e linear, mas reescreve os commits da sua branch — portanto, evite fazer rebase em uma branch que outros já baixaram. A regra geral: faça rebase na sua própria branch privada e mescle qualquer coisa compartilhada.

Lidando com conflitos

Quando duas branches alteram as mesmas linhas, a mesclagem ou o rebase para e pede que você resolva o conflito. O Git marca as regiões conflitantes nos arquivos afetados; você as edita, faz o stage e continua. O processo completo está em Resolvendo conflitos de mesclagem.

Salvando trabalho em andamento

Se você precisar trocar de branch, mas não estiver pronto para fazer um commit, git stash guarda suas mudanças não commitadas para que você possa se mover livremente e restaurá-las depois:

git stash            # set current changes aside
git switch main      # do something urgent
git switch feature/login-form
git stash pop        # bring the changes back

Benefícios e trade-offs

O workflow de feature branch é popular porque é fácil de entender, integra-se naturalmente com pull requests e revisão de código, e mantém a main pronta para deploy em todos os momentos.

Seu principal risco são as branches de longa duração: quanto mais tempo uma branch existe, mais ela diverge da main e mais difícil se torna a mesclagem eventual ("merge hell"). Para evitar isso:

• Mantenha as branches pequenas e de curta duração — idealmente mescladas em um ou dois dias.
• Traga a main para sua branch (ou faça rebase) regularmente, não apenas no final.
• Divida funcionalidades grandes em várias branches menores que sejam mescladas de forma independente.
• Nunca faça commits diretamente na main — isso anula o propósito do workflow.

Quando as equipes precisam de branches de release, branches de hotfix e um processo de promoção rigoroso além disso, elas frequentemente adotam um modelo mais completo, como Git Flow ou desenvolvimento baseado em trunk — mas a feature branch é o bloco de construção subjacente a todos eles.

Prática