{ freetool24 }
Developer Tools

Guia de Workflow com Git: Branches, Merges e Colaboração em Equipe

Domine estratégias de branching no Git, boas práticas de commit, rebase vs. merge e os workflows utilizados por equipes de engenharia profissionais.

8 min de leitura

Desenvolvedor olhando para código em uma tela

Git é a base do workflow de todo time de software moderno. Ainda assim, muitos desenvolvedores usam apenas commit, push e pull — deixando de lado os recursos que tornam o desenvolvimento colaborativo fluido e livre de conflitos. Este guia aborda as estratégias de branching, práticas de commit e comandos do dia a dia utilizados por equipes profissionais.

O modelo mental central

Git é um grafo acíclico dirigido de snapshots (commits). Cada commit aponta para seu(s) pai(s). Branches são simplesmente ponteiros nomeados para commits — leves e baratos de criar.

main:    A → B → C → D
feature:         C → E → F

Criar um branch não copia arquivos — apenas cria um novo ponteiro. Por isso, criar um branch leva milissegundos, independentemente do tamanho do repositório.

Estratégias de branching

GitHub Flow (simples, entrega contínua)

Ideal para times que fazem deploy com frequência:

  1. main está sempre pronto para deploy
  2. Crie um branch de feature para cada mudança
  3. Abra um pull request quando estiver pronto para revisão
  4. Faça merge para main após aprovação
  5. Faça deploy imediatamente
git checkout -b feature/add-user-auth
# ... faça as alterações ...
git push origin feature/add-user-auth
# Abra o PR → revisão → merge → deploy

Git Flow (releases estruturadas)

Ideal para produtos com releases versionadas (apps, bibliotecas):

  • main — apenas código em produção
  • develop — branch de integração
  • feature/* — novas funcionalidades (criadas a partir de develop)
  • release/* — preparação de release (criada a partir de develop)
  • hotfix/* — correções urgentes em produção (criadas a partir de main)

Mais estruturado, porém adiciona overhead. Use GitHub Flow a menos que você tenha uma necessidade real de gerenciamento paralelo de releases.

Trunk-Based Development

Desenvolvedores fazem commit diretamente em main (ou branches de curta duração com menos de 1 dia). Feature flags controlam o que os usuários veem. Exige CI/CD sólido e boa cobertura de testes. Utilizado pelo Google, Facebook e times de alta velocidade.

Escrevendo boas mensagens de commit

A mensagem de commit é uma carta para o seu eu do futuro (e para os colegas de time). Siga o formato Conventional Commits:

<tipo>(<escopo>): <resumo curto>

<corpo opcional — o quê e por quê, não o como>

<rodapé opcional — breaking changes, referências a issues>

Tipos:

  • feat — nova funcionalidade
  • fix — correção de bug
  • docs — apenas documentação
  • refactor — mudança de código que não corrige bug nem adiciona funcionalidade
  • test — adição ou correção de testes
  • chore — processo de build, dependências, ferramentas

Exemplos:

feat(auth): add JWT refresh token rotation

Implements sliding session windows using refresh token rotation.
Previous tokens are invalidated on use to detect theft.

Closes #142

fix(api): return 404 instead of 500 for missing user

The /users/:id endpoint was throwing an unhandled exception when
the user didn't exist. Now returns a proper 404 with error message.

Regra prática: Se sua mensagem de commit é fix stuff ou WIP, sua equipe odeia você. Seja descritivo.

Merge vs. Rebase

Merge

git checkout main
git merge feature/my-feature

Cria um merge commit que une dois branches. Preserva o histórico completo — você consegue ver exatamente quando os branches divergiram e foram mesclados.

A → B → C → M (merge commit)
         ↑   ↑
         E → F (feature)

Use merge para: integrar branches de longa duração, preservar contexto no histórico.

Rebase

git checkout feature/my-feature
git rebase main

Reaplicar seus commits sobre o branch de destino. Cria um histórico linear — parece que a feature foi construída em cima do main mais recente.

Antes: A → B → C (main)
                ↑
           D → E (feature, baseada em B)

Depois: A → B → C → D' → E' (feature rebaseada sobre C)

Use rebase para: limpar commits locais antes de um PR, manter branches de feature atualizados.

Regra de ouro: Nunca faça rebase de commits que já foram enviados para um branch compartilhado. O rebase reescreve o histórico — isso quebra os branches locais de outras pessoas.

Rebase interativo: limpando o histórico

Antes de abrir um PR, faça squash e fixup de commits bagunçados de trabalho em progresso:

git rebase -i HEAD~4   # edite interativamente os últimos 4 commits

Opções no editor interativo:

  • pick — manter o commit
  • squash — mesclar no commit anterior, combinando as mensagens
  • fixup — mesclar no commit anterior, descartando a mensagem
  • reword — manter as alterações, editar a mensagem
  • drop — excluir o commit completamente

Lidando com conflitos

Conflitos acontecem quando dois branches modificam as mesmas linhas. O Git os marca assim:

<<<<<<< HEAD (seu branch)
const timeout = 5000;
=======
const timeout = 3000;
>>>>>>> feature/update-timeouts

Resolva editando o arquivo para o estado correto (removendo os marcadores) e depois:

git add src/config.ts
git merge --continue   # ou git rebase --continue

Prevenir é melhor que remediar:

  • Faça pull do main com frequência para manter os branches de curta duração
  • Comunique-se com os colegas quando trabalhar nos mesmos arquivos
  • Mantenha os PRs pequenos — PRs grandes têm mais conflitos e revisões mais difíceis

Comandos essenciais do dia a dia

# Iniciar uma nova feature
git checkout -b feature/my-feature

# Staged apenas mudanças específicas (não o arquivo inteiro)
git add -p

# Ver mudanças sem stage
git diff

# Ver mudanças com stage
git diff --staged

# Alterar o último commit (antes do push)
git commit --amend --no-edit

# Salvar temporariamente trabalho não commitado
git stash
git stash pop

# Encontrar qual commit introduziu um bug (busca binária)
git bisect start
git bisect bad              # commit atual está com bug
git bisect good v1.2.0      # último commit sabidamente bom

# Recuperar um branch deletado ou commit perdido
git reflog

# Ver um gráfico visual dos branches
git log --oneline --graph --all

Boas práticas de pull request

Um bom PR:

  • Faz uma coisa só — os revisores conseguem entender a mudança completa
  • Tem uma descrição clara — o que mudou, por quê e como testar
  • É pequeno — menos de 400 linhas de diff como referência aproximada
  • Passa no CI — nunca peça revisão com uma build quebrada
  • Referencia a issue — Closes #42 fecha a issue automaticamente ao fazer merge

Use nosso README Generator para criar documentação junto com suas mudanças de código.

Essenciais do .gitignore

Sempre adicione estes itens ao .gitignore:

# Variáveis de ambiente
.env
.env.local
.env.*.local

# Dependências
node_modules/
vendor/

# Saída de build
dist/
build/
.next/

# Arquivos do sistema operacional
.DS_Store
Thumbs.db

# Arquivos de editor
.vscode/settings.json
.idea/
*.swp

Gere um .gitignore específico para o seu projeto em gitignore.io — ele conhece centenas de linguagens e ferramentas.

O domínio do Git se aprimora com o tempo. Aprenda o modelo mental, adote boas práticas de commit e a colaboração da sua equipe ficará dramaticamente mais fluida.

Voltar a todos os artigosVer ferramentas