Feature Branch no Git: o que é, como criar e trabalhar com ramos

O que é um Feature Branch no Git

Feature Branch (ramo de funcionalidade) é um ramo temporário no Git criado a partir de develop para desenvolver uma funcionalidade específica. Ao contrário dos ramos de longa duração main e develop, os ramos feature existem por um tempo limitado — de algumas horas a algumas semanas.

O principal objetivo do feature branch é isolar as alterações relacionadas a uma tarefa do resto do código. O desenvolvedor pode experimentar, fazer vários commits e até quebrar o código em seu próprio ramo sem afetar o trabalho de outros membros da equipe.

Após a conclusão do desenvolvimento, o ramo feature é mesclado de volta ao develop por meio de um Pull Request com revisão de código obrigatória. Após a mesclagem, o ramo geralmente é excluído para manter o repositório limpo.

De acordo com Vincent Driessen, 2010, o modelo Git Flow com ramos feature tornou-se um padrão da indústria graças à clara separação de responsabilidades entre diferentes tipos de ramos.

Fluxo de trabalho com Feature Branch

O fluxo de trabalho com feature branch consiste em uma sequência de etapas que o desenvolvedor realiza para cada nova funcionalidade. Esse processo minimiza os conflitos de mesclagem e garante o controle de qualidade do código.

1. Criação do ramo a partir do último commit de develop. O desenvolvedor muda para develop, atualiza-o e cria um novo ramo feature.
2. Desenvolvimento e commits no ramo feature. O desenvolvedor faz alterações, faz commits com descrições claras e envia periodicamente o ramo para o repositório remoto.
3. Sincronização com develop — durante o desenvolvimento, o ramo principal pode avançar. O desenvolvedor realiza um rebase ou merge de develop em seu ramo feature.
4. Criação de um Pull Request — quando a funcionalidade está pronta, o desenvolvedor abre um PR para revisão de código. A equipe revisa o código e deixa comentários.
5. Mesclagem e exclusão — após a aprovação do PR, o ramo é mesclado ao develop e excluído tanto local quanto remotamente.

A sincronização periódica com develop é criticamente importante. Quanto mais tempo um ramo feature viver sem mesclar alterações do develop, maior a probabilidade de conflitos na mesclagem final.

Frequência de sincronização do ramo feature

Regras de nomenclatura de ramos feature

A nomenclatura de ramos é uma parte importante da disciplina da equipe. Um padrão de nomenclatura uniforme permite identificar rapidamente em qual tarefa se está trabalhando e quem a está realizando.

• feature/nome — o prefixo feature/ é usado no Git Flow clássico. Exemplo: feature/added-auth-module.
• feature/JIRA-123-descrição — vinculação ao número da tarefa no sistema de rastreamento. Exemplo: feature/PROJ-42-add-login.
• feature/tipo/nome — formato estendido com indicação do tipo de tarefa. Exemplo: feature/feat/analytics-dashboard.

O uso do ID da tarefa do JIRA, Trello ou outro sistema é uma prática recomendada. Ele vincula automaticamente o código à tarefa e simplifica a busca de ramos através do git log.

Processo de Pull Request

Pull Request (ou Merge Request no GitLab) é uma solicitação para mesclar o ramo feature em develop. Um PR não é apenas uma operação técnica, mas um processo de revisão de código em equipe que melhora a qualidade do código e dissemina o conhecimento dentro da equipe.

Um bom PR contém um título com uma breve descrição da tarefa, um link para o ticket e uma descrição das alterações. O desenvolvedor deve indicar o que exatamente foi feito, quais arquivos foram alterados e se existem riscos potenciais para outras partes do projeto.

A equipe revisa o código no PR, deixa comentários, solicita alterações (change requests) e aprova a mesclagem (approve). Após a aprovação, é realizado um merge ou squash merge.

O tempo médio de revisão de PR no desenvolvimento móvel é de 4 a 24 horas. A biblioteca Danger automatiza parte das verificações, executando linters e testes diretamente no PR.

Recomendações para criar um bom PR

• Tamanho — não mais que 300-400 linhas de alterações. PRs grandes são difíceis de revisar e a qualidade da revisão diminui.
• Um PR — uma tarefa — evite misturar alterações não relacionadas em uma mesma solicitação.
• Capturas de tela — para alterações de UI, anexe capturas de tela antes e depois.
• Testes — para nova funcionalidade, escreva testes unitários e inclua-os no PR.

Estratégias de mesclagem de ramos feature

Após a aprovação do PR, o ramo feature pode ser mesclado ao develop de diferentes maneiras. A escolha da estratégia de mesclagem afeta o histórico de commits e a possibilidade de reverter alterações.

• Merge commit — cria um commit de mesclagem, preservando todo o histórico de commits do ramo feature. O histórico permanece completo, mas o gráfico de ramificações se torna mais complexo.
• Squash merge — combina todos os commits do ramo feature em um único e adiciona sobre develop. O histórico fica mais limpo, mas informações sobre commits intermediários são perdidas.
• Rebase and merge — reescreve os commits do ramo feature sobre o último commit de develop e mescla sem um commit adicional. O histórico permanece linear.

Para projetos móveis com lançamentos frequentes, o squash merge é o mais utilizado: fornece um histórico limpo em develop, enquanto os detalhes do desenvolvimento permanecem na descrição do PR e na tarefa do tracker.

Erros típicos ao trabalhar com Feature Branch

Mesmo desenvolvedores experientes cometem erros ao trabalhar com ramos feature. Conhecer os problemas típicos ajuda a evitar perda de tempo e dados.

• Vida muito longa do ramo — um ramo feature vive mais de 2-3 semanas sem sincronização com develop, levando a conflitos de mesclagem massivos.
• Commits com descrições pouco claras — mensagens como “fix” ou “update” não permitem entender o que foi alterado e porquê.
• Mistura de tarefas — em um mesmo ramo feature são desenvolvidas duas funcionalidades não relacionadas, tornando a reversão seletiva impossível.
• Falta de sincronização — o desenvolvedor não executa git fetch nem atualiza develop, causando conflitos na mesclagem final.

A melhor maneira de evitar esses problemas é concordar com as regras de trabalho no início do projeto e usar verificações automatizadas no pipeline de CI/CD.

Exemplos de comandos para trabalhar com Feature Branch

Vamos considerar um cenário prático: um desenvolvedor inicia uma nova funcionalidade de autenticação em um aplicativo móvel. Ele cria um ramo feature, trabalha no código e conclui a tarefa com um Pull Request.

# Atualizar develop e criar ramo feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Trabalho na funcionalidade: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Enviar ramo feature para o servidor remoto
git push origin feature/add-login-screen

# Sincronização com develop (rebase)
git fetch origin develop
git rebase origin/develop

# Após aprovação do PR: atualizar develop local e excluir o ramo
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

O comando git branch -d exclui o ramo apenas depois que suas alterações foram totalmente mescladas. Se o ramo não estiver mesclado, o Git sugerirá usar git branch -D para exclusão forçada — use esta flag com cautela.

Automatização de verificações no ramo feature

O pipeline de CI/CD deve ser executado para cada ramo feature antes de criar um PR. Isso permite detectar problemas em um estágio inicial, antes que o código chegue à revisão de outros desenvolvedores.

# GitHub Actions para verificar o ramo feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

O pipeline verifica se o código compila, os testes passam e o estilo do código atende aos padrões da equipe. Somente após passar em todas as verificações é que um Pull Request pode ser criado.