Hotfix Branch: o que é, como criar e usar no desenvolvimento mobile

O que é Hotfix Branch?

Hotfix Branch é uma branch temporária no Git criada para corrigir rapidamente defeitos críticos em um ambiente de produção ativo. Ao contrário das branches feature, que ramificam a partir do develop e duram vários dias ou semanas, um hotfix é criado a partir do main/master e existe exatamente pelo tempo necessário para corrigir o bug.

O principal objetivo do hotfix é minimizar o tempo entre a descoberta de um erro crítico e sua correção em produção. A equipe não espera o fim da sprint atual ou do ciclo de lançamento — ela publica um patch imediatamente. Isso é especialmente importante para aplicativos móveis, onde um bug crítico pode bloquear usuários e levar à evasão.

De acordo com o Google Play Console, o tempo médio de revisão de atualização no Google Play é de 2 a 24 horas. Para a App Store, a revisão expressa pode levar de 1 a 4 horas. As branches hotfix permitem preparar a correção antes que a moderação termine e publicá-la imediatamente após a aprovação.

Como o Hotfix funciona

O processo de hotfix consiste em três etapas: criar uma branch a partir do main, fazer a correção e mesclar de volta no main e develop. A principal diferença de uma correção normal é que o hotfix é sempre mesclado em ambas as branches, para que a correção não se perca no próximo lançamento.

A equipe não deve introduzir nova funcionalidade ou refatoração em um hotfix. Apenas uma correção pontual, minimamente necessária para resolver o problema crítico. Qualquer desvio dessa regra aumenta o risco de regressão e atrasa a publicação do patch.

Quando um Hotfix é necessário

Um hotfix é necessário em três cenários: um bug crítico bloqueia usuários (crash, perda de dados), uma vulnerabilidade de segurança requer fechamento imediato, ou a lógica de negócio crítica está quebrada (pagamentos, autenticação). Se o bug não for crítico — ele pode ser corrigido dentro do ciclo de lançamento normal através do develop.

Para aplicativos móveis, um hotfix também pode incluir alterações no servidor se a arquitetura permitir a alternância remota de recursos (feature flags). Nesse caso, a branch hotfix pode ser mínima ou nem ser necessária se a correção puder ser feita no lado do servidor.

Modelos de ramificação e lugar do Hotfix

Nem todos os modelos de ramificação suportam branches hotfix. O Git Flow tradicional inclui o hotfix como um tipo de branch completo, enquanto abordagens mais modernas (GitHub Flow, Trunk-based) lidam com correções emergenciais de forma diferente.

Git Flow e Hotfix

Git Flow é o único modelo onde o hotfix é um tipo de branch integrado juntamente com feature e release. No Git Flow, um hotfix é criado a partir do main e, ao ser concluído, é mesclado tanto no main (com uma tag de versão) quanto no develop. Isso garante que a correção não se perca no próximo lançamento.

GitHub Flow e Trunk-based

GitHub Flow não usa um tipo de branch separado para hotfix. Em vez disso, o desenvolvedor cria uma branch feature normal a partir do main, faz a correção e abre um Pull Request. Após a revisão e verificações de CI, a branch é mesclada no main e implantada imediatamente. A vantagem é a simplicidade; a desvantagem é a falta de um canal dedicado para correções urgentes.

O desenvolvimento Trunk-based lida com hotfix através de commits diretamente no main (para casos críticos) com revisão obrigatória posterior. Essa abordagem requer alta disciplina da equipe e testes automatizados confiáveis, já que as alterações vão para produção instantaneamente.

Como criar um Hotfix Branch

Criar um hotfix começa alternando para a branch principal e criando uma nova branch com o prefixo hotfix/. Vamos examinar o processo passo a passo com o exemplo de correção de um bug crítico em um aplicativo móvel.

Criar uma branch a partir do main

Primeiro passo — alternar para o main e garantir que a branch esteja atualizada. Em seguida, criar uma branch hotfix com um nome claro que reflita a natureza da correção.

# Mudar para main e obter as últimas alterações
git checkout main
git pull origin main

# Criar uma branch hotfix
git checkout -b hotfix/crash-on-login

Após criar a branch, você pode fazer a correção. É importante lembrar: um hotfix deve conter um número mínimo de alterações. Não refatore código nem adicione novos recursos — apenas a correção pontual que resolve o problema.

Confirmar a correção

O commit em um hotfix deve ter uma mensagem informativa que descreva claramente o problema e sua solução. Formato: tipo(escopo): descrição breve + link para a tarefa no tracker.

# Adicionar arquivos modificados
git add src/ui/login/LoginActivity.kt

# Criar um commit com descrição
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

A mensagem de commit deve conter uma descrição do problema e um link para a tarefa. Isso simplifica a busca no histórico e ajuda os colegas a entender o que foi corrigido e por quê. Para projetos móveis, também é comum incluir a versão do aplicativo onde o bug foi encontrado.

Mesclagem no main e develop

O passo final é mesclar o hotfix de volta no main (com uma tag de nova versão de patch) e no develop (para que a correção seja preservada no próximo lançamento). Primeiro, mescle no main com uma tag, depois mescle no develop.

# Mesclar no main e criar uma tag
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Mesclar no develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Enviar alterações para o servidor
git push origin main --tags
git push origin develop

A flag --no-ff garante a criação de um commit de mesclagem, mesmo que o hotfix pudesse ser aplicado via fast-forward. Isso preserva a informação de que uma correção de emergência foi realizada e simplifica a análise do histórico no futuro.

Diferença entre Hotfix, Feature e Release

Um hotfix é fundamentalmente diferente das branches feature e release em termos de objetivo, tempo de vida e regras de mesclagem. Compreender essas diferenças é crítico para organizar adequadamente os processos Git em uma equipe.

Uma branch feature é destinada a nova funcionalidade. Ela dura de vários dias a várias semanas, é criada a partir do develop e mesclada de volta no develop. Uma feature pode conter vários commits, incluindo experimentais, que são posteriormente comprimidos via squash ou rebase.

Uma branch release prepara um lançamento para implantação. Ela é criada a partir do develop, bugs encontrados durante a estabilização são corrigidos nela, e ela não aceita nova funcionalidade. Após a conclusão, a release é mesclada no main (com tag) e develop.

Um hotfix, por outro lado, é criado e mesclado diretamente com o main, ignorando o develop (embora após a correção seja sincronizado também com o develop). Ele contém um número mínimo de alterações e existe por um tempo mínimo. Enquanto branches feature ou release podem ser adiadas até o próximo ciclo, um hotfix não pode.

Para o desenvolvimento mobile, essa distinção é especialmente importante: a App Store e o Google Play permitem publicar versões de patch separadamente dos lançamentos principais. A branch hotfix garante que um lançamento de patch não se misture com funcionalidades inacabadas.

Erros típicos ao trabalhar com Hotfix

Erros ao trabalhar com hotfix podem anular as vantagens da correção emergencial. Vamos analisar os cinco problemas mais comuns que surgem em equipes que usam Git Flow.

• Criar um hotfix a partir do develop — se um hotfix for criado a partir do develop, funcionalidades inacabadas podem entrar no patch. O hotfix deve ser criado apenas a partir do main para garantir que apenas código estável seja incluído na correção.
• Várias correções em um mesmo hotfix — cada correção deve estar em sua própria branch hotfix. Misturar vários bugs em uma mesma branch complica a revisão de código, aumenta o risco de regressão e dificulta o rollback se necessário.
• Pular a mesclagem no develop — se um hotfix não for mesclado no develop, a correção será perdida no próximo lançamento. A equipe descobrirá que o mesmo bug reapareceu e terá que corrigi-lo novamente.
• Tag de versão incorreta — um hotfix deve receber um incremento de patch (v2.3.0 → v2.3.1), não um menor (v2.4.0) ou maior (v3.0.0). Violar o versionamento semântico quebra o sistema de build e confunde os usuários.
• Falta de verificações de CI — mesmo um hotfix emergencial deve passar por testes automatizados. Pular o CI aumenta o risco de introduzir um novo erro. Recomenda-se ter um pipeline separado para branches hotfix com verificações aceleradas.

Cada um desses erros leva a um atraso na publicação do patch ou ao surgimento de novos problemas em produção. As equipes devem documentar as regras de trabalho com hotfix no CONTRIBUTING.md e automatizá-las através de verificações CI/CD.