Pratique Estratégias de Branch Git

O que você aprenderá neste tutorial

• Operações básicas de branch
• Feature Branch Workflow
• Diferenças entre Git Flow e GitHub Flow
• Quando usar merge vs rebase
• Resolução de conflitos

O que é Estratégia de Branch? Por que é Importante?

História das Estratégias de Branch

As estratégias de branch começaram a ganhar atenção no final dos anos 2000, quando o desenvolvimento em equipe se tornou mais complexo.

Em 2010, Vincent Driessen publicou o artigo “A successful Git branching model” propondo o Git Flow. Esta foi a primeira estratégia de branch sistemática a ser amplamente adotada.

Posteriormente, o GitHub propôs o GitHub Flow em 2011, mais simples. Este modelo ganhou apoio como ideal para equipes que fazem deploy contínuo.

“A estratégia de branch deve ser escolhida de acordo com o fluxo de trabalho da equipe. Não existe uma estratégia universal” — Vincent Driessen, artigo complementar de 2020

Por que Precisamos de Estratégia de Branch?

1. Desenvolvimento paralelo: Múltiplas funcionalidades podem ser desenvolvidas simultaneamente
2. Isolamento de risco: Código instável é isolado da linha principal
3. Code review: Garantia de qualidade através de pull requests
4. Gerenciamento de releases: Controle de implantação em produção

Comparação das Principais Estratégias de Branch

Operações Básicas de Branch

Criação e Troca de Branch

# Listar branches
git branch

# Listar incluindo branches remotos
git branch -a

# Criar novo branch
git branch feature/login

# Trocar de branch
git checkout feature/login

# Criar e trocar simultaneamente (recomendado)
git checkout -b feature/login

# Novo comando a partir do Git 2.23 (recomendado)
git switch -c feature/login
git switch feature/login

Documentação oficial: git-branch

Convenções de Nomenclatura de Branch

É importante usar convenções de nomenclatura consistentes na equipe:

# Desenvolvimento de funcionalidade
feature/user-authentication
feature/payment-integration

# Correção de bugs
fix/login-button-crash
bugfix/memory-leak

# Correção urgente
hotfix/security-vulnerability

# Preparação de release
release/v1.2.0

# Funcionalidade experimental
experiment/new-algorithm

Melhor prática: Nomes de branch em minúsculas, separados por hífen, incluir número do ticket para facilitar rastreamento (ex: feature/JIRA-123-add-login)

Operações com Branches Remotos

# Listar incluindo branches remotos
git branch -a

# Fazer checkout de branch remoto para local
git checkout -b feature/login origin/feature/login

# Ou (a partir do Git 2.23)
git switch feature/login  # Rastreia automaticamente o remoto

# Fazer push do branch para o remoto
git push -u origin feature/login

# Deletar branch remoto
git push origin --delete feature/login

# Deletar branch local
git branch -d feature/login

# Forçar deleção de branch não mesclado
git branch -D feature/login

Verificação de Status do Branch

# Verificar diferenças entre branches
git diff main..feature/login

# Mostrar branches mesclados
git branch --merged

# Mostrar branches não mesclados
git branch --no-merged

# Mostrar último commit de cada branch
git branch -v

Feature Branch Workflow

A estratégia de branch mais básica. Crie um branch para cada funcionalidade e faça merge no branch principal quando concluído.

Diagrama do Workflow

gitGraph
    commit
    branch feature/A
    commit
    commit
    commit
    commit
    checkout main
    merge feature/A
    commit

Cenário Prático: Adicionando Funcionalidade de Login

# 1. Atualizar branch principal
git checkout main
git pull origin main

# 2. Criar branch de funcionalidade
git checkout -b feature/login

# 3. Implementação e commits
# (editar código)
git add .
git commit -m "feat: Add login form component"

# (mais implementação)
git add .
git commit -m "feat: Add login API integration"

# (adicionar testes)
git add .
git commit -m "test: Add login validation tests"

# 4. Push para o remoto
git push -u origin feature/login

# 5. Criar pull request (no GitHub)

# 6. Após review, fazer merge

Melhores Práticas para Pull Requests

“Mantenha pull requests pequenos. O tamanho ideal é aquele que o revisor pode verificar em 20 minutos” — Google Engineering Practices

1. Tamanho apropriado: 200-400 linhas como meta
2. Propósito único: 1 funcionalidade/correção por PR
3. Descrição detalhada: Inclua contexto, alterações e como testar
4. Auto-review: Verifique você mesmo antes de submeter

Git Flow

Estratégia para projetos com ciclo de release claro. Proposta por Vincent Driessen em 2010.

Branches Principais

flowchart TB
    main["main (ou master)"]
    develop["develop (branch de integração)"]
    feature["feature/* (desenvolvimento de funcionalidade)"]
    release["release/* (preparação de release)"]
    hotfix["hotfix/* (correção urgente de bug)"]

    main --> develop
    develop --> feature
    develop --> release
    main --> hotfix

Git Flow na Prática

# Criar branch de funcionalidade a partir de develop
git checkout develop
git checkout -b feature/user-profile

# Após conclusão da funcionalidade, merge em develop
git checkout develop
git merge --no-ff feature/user-profile
git branch -d feature/user-profile

# Preparação de release
git checkout -b release/1.0.0 develop

# Atualização de versão, correções de bugs, etc.
git commit -m "chore: Bump version to 1.0.0"

# Conclusão do release
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Version 1.0.0"

git checkout develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0

# Correção urgente (Hotfix)
git checkout main
git checkout -b hotfix/security-fix

# Após correção
git checkout main
git merge --no-ff hotfix/security-fix
git tag -a v1.0.1 -m "Security patch"

git checkout develop
git merge --no-ff hotfix/security-fix
git branch -d hotfix/security-fix

Ferramenta git-flow

O comando git-flow simplifica as operações:

# Instalação
# macOS
brew install git-flow

# Ubuntu
apt install git-flow

# Inicialização
git flow init

# Desenvolvimento de funcionalidade
git flow feature start user-profile
git flow feature finish user-profile

# Release
git flow release start 1.0.0
git flow release finish 1.0.0

# Hotfix
git flow hotfix start security-fix
git flow hotfix finish security-fix

Quando Usar Git Flow

Adequado:

• Ciclo de release regular
• Necessidade de suportar múltiplas versões
• Existência de equipe de QA

Não adequado:

• Deploy contínuo
• Equipe pequena
• Aplicação web com apenas versão mais recente em produção

Complemento de Vincent Driessen em 2020: “Agora que deploy contínuo se tornou comum no desenvolvimento web, Git Flow é excessivo para muitos projetos. Considere modelos mais simples como GitHub Flow”

GitHub Flow

Estratégia simples adequada para deploy contínuo. Recomendada oficialmente pelo GitHub.

Diagrama do Workflow

gitGraph
    commit
    branch pr-1
    commit
    commit
    commit
    checkout main
    merge pr-1
    branch pr-2
    commit
    commit
    commit
    checkout main
    merge pr-2
    commit

6 Regras

1. main sempre deployável
2. Funcionalidades ramificam de main
3. Push regularmente para o remoto
4. Code review via pull request
5. Merge em main após review
6. Deploy imediatamente após merge

Blog Oficial do GitHub: GitHub Flow

GitHub Flow na Prática

# Criar branch de funcionalidade a partir de main
git checkout main
git pull origin main
git checkout -b add-dark-mode

# Desenvolvimento e commits (pequenos e frequentes)
git add .
git commit -m "feat: Add dark mode toggle"
git push -u origin add-dark-mode

# Criar pull request (no GitHub)
# Code review
# Pipeline CI/CD executa automaticamente

# Após aprovação do PR, merge e deploy
# Após merge, deletar branch
git checkout main
git pull origin main
git branch -d add-dark-mode

Quando Usar GitHub Flow

Adequado:

• Deploy contínuo
• Apenas versão mais recente em produção
• Equipe pequena a média

Trunk Based Development

Estratégia adotada por equipes grandes como Google e Facebook.

Características

• Merge diretamente no branch main (trunk) ou de branches de curta duração
• Branches são mesclados em 1-2 dias
• Funcionalidades grandes são controladas por feature flags

gitGraph
    commit
    branch short-1
    commit
    checkout main
    merge short-1
    branch short-2
    commit
    checkout main
    merge short-2
    branch short-3
    commit
    checkout main
    merge short-3
    commit

Referência: trunkbaseddevelopment.com

Merge vs Rebase

Merge

Preserva o histórico e cria um commit de merge.

# Merge feature/login em main
git checkout main
git merge feature/login

# Sempre criar commit de merge (--no-ff)
git merge --no-ff feature/login

Resultado:

gitGraph
    commit
    branch feature
    commit
    commit
    checkout main
    merge feature

Rebase

Reescreve o histórico de forma linear.

# Incorporar o mais recente de main no branch de feature
git checkout feature/login
git rebase main

# Rebase interativo (organizar commits)
git rebase -i HEAD~3

Resultado (após rebase):

• Commits da feature aparecem linearmente após os commits mais recentes de main
• Nenhum commit de merge é criado

Qual Usar?

Regra de ouro: “Nunca faça rebase de commits compartilhados com outras pessoas”

Organizar Commits com Rebase Interativo

git rebase -i HEAD~3

O editor abre:

pick abc1234 WIP: trabalho em progresso
pick def5678 fix: typo
pick ghi9012 feat: Adiciona funcionalidade de login

# Commands:
# p, pick = usar commit
# r, reword = editar mensagem
# s, squash = combinar com commit anterior
# f, fixup = combinar com commit anterior (descartar mensagem)
# d, drop = deletar commit

# Organizar commits
pick abc1234 WIP: trabalho em progresso
squash def5678 fix: typo
squash ghi9012 feat: Adiciona funcionalidade de login

Resolução de Conflitos

Como Conflitos Ocorrem

flowchart TB
    Original["main: Hello World"]
    OtherMerge["Hello Everyone<br/>(merge de outra pessoa)"]
    YourChange["feature: Hello Universe<br/>(sua alteração)"]
    Conflict["Conflito ocorre!"]

    Original --> OtherMerge
    Original --> YourChange
    OtherMerge --> Conflict
    YourChange --> Conflict

Procedimento de Resolução de Conflitos

# Quando conflito ocorre durante merge
git status  # Verificar arquivos com conflito

# Editar arquivo para resolver conflito

Marcadores de conflito:

<<<<<<< HEAD
Conteúdo do branch atual
=======
Conteúdo do branch sendo mesclado
>>>>>>> feature/login

Após resolução:

# Fazer staging do arquivo com conflito resolvido
git add conflicted-file.js

# Concluir merge
git commit -m "merge: Resolve conflict between header and footer"

# Ou, para abortar o merge
git merge --abort

Melhores Práticas para Resolução de Conflitos

1. Merge/rebase de main frequentemente: Manter conflitos pequenos
2. Comunicação: Consulte antecipadamente se editar os mesmos arquivos
3. Use ferramentas: VS Code, GitKraken e outras ferramentas GUI
4. Execute testes: Sempre execute testes após resolver

Resolução de Conflitos no VS Code

VS Code permite resolver conflitos visualmente:

Accept Current Change  | Accept Incoming Change  | Accept Both Changes

Prática: Simulação de Desenvolvimento em Equipe

Reproduza um cenário onde 2 desenvolvedores experimentam um conflito.

# 1. Inicializar repositório
mkdir team-dev-simulation
cd team-dev-simulation
git init
echo "# Team Project" > README.md
git add README.md
git commit -m "Initial commit"

# 2. Branch do Desenvolvedor A
git checkout -b feature/header
echo "<header>Header A</header>" > index.html
git add index.html
git commit -m "feat: Add header by Dev A"

# 3. Voltar para main e branch do Desenvolvedor B
git checkout main
git checkout -b feature/footer
echo "<footer>Footer B</footer>" > index.html
git add index.html
git commit -m "feat: Add footer by Dev B"

# 4. Merge feature/header primeiro
git checkout main
git merge feature/header

# 5. Merge feature/footer (conflito ocorre!)
git merge feature/footer
# CONFLICT (add/add): Merge conflict in index.html

# 6. Resolver conflito
# Editar index.html para incluir ambas alterações
cat > index.html << 'EOF'
<header>Header A</header>
<footer>Footer B</footer>
EOF

git add index.html
git commit -m "merge: Resolve conflict between header and footer"

Guia de Escolha de Estratégia de Branch

Responda as Perguntas para Escolher o Fluxo

1. Você faz deploy contínuo?

   • Sim → GitHub Flow ou Trunk Based
   • Não → Considere Git Flow

2. Qual é o ciclo de release?

   • Diário a várias vezes por semana → GitHub Flow
   • Semanal a mensal → Git Flow
   • Múltiplas vezes ao dia → Trunk Based

3. Qual o tamanho da equipe?

   • 1-5 pessoas → GitHub Flow
   • 5-20 pessoas → GitHub Flow ou Git Flow
   • 20+ pessoas → Trunk Based (feature flags obrigatórios)

Erros Comuns e Antipadrões

1. Branches de Longa Duração

# Antipadrão: Branch sem merge por semanas
# Conflitos se tornam enormes, merge se torna difícil

# Melhor prática: Merge frequentemente
git checkout feature/big-feature
git fetch origin
git rebase origin/main  # Executar diariamente

2. Rebase Após Push

# Perigoso! Reescrever commits compartilhados
git push origin feature/x
git rebase -i HEAD~3
git push --force  # Sobrescreve alterações de outros

# Seguro: Usar force-with-lease
git push --force-with-lease

3. Commits Diretos em Main

# Antipadrão
git checkout main
git commit -m "Quick fix"

# Melhor prática: Sempre passar por PR
git checkout -b fix/quick-fix
git commit -m "Quick fix"
git push -u origin fix/quick-fix
# Criar PR

Links de Referência

Documentação Oficial e Originais

• A successful Git branching model - Artigo original de Vincent Driessen
• GitHub Flow - Documentação oficial do GitHub
• Trunk Based Development - Explicação detalhada de TBD

Ferramentas

• git-flow - Extensão Git para Git Flow
• GitHub CLI - Gerencie PRs pela linha de comando

Artigos Relacionados e Livros

• Atlassian Git Tutorials - Branching - Comparação de vários workflows
• Pro Git Book - Branching - Explicação detalhada de branches
• Google Engineering Practices - Melhores práticas de code review