Questão de Engenharia de Software — Geral — FCC 2025

Gitflow: Hotfix para Correção Crítica em Produção

Gabarito: letra D. No modelo Gitflow, uma correção crítica e urgente em produção deve ser tratada em uma branch do tipo hotfix, criada a partir da main (ou master), pois é a única forma de corrigir o problema rapidamente sem arrastar mudanças de desenvolvimento ainda não publicadas. As demais alternativas violam o fluxo do Gitflow ao reescrever histórico, aguardar sprint, usar a develop ou reutilizar uma release já publicada.

O Gitflow é um modelo de ramificação (branching model) para Git, proposto por Vincent Driessen, que organiza o ciclo de vida do desenvolvimento em branches com papéis bem definidos. As branches principais são a main (ou master), que contém o código estável e pronto para produção, e a develop, que integra as funcionalidades em desenvolvimento. A partir delas, derivam-se branches de suporte: feature (novas funcionalidades, criadas a partir da develop), release (preparação de uma nova versão, criada a partir da develop) e hotfix (correções urgentes, criadas a partir da main).

A lógica por trás do hotfix é simples: quando um bug crítico é encontrado em produção, não se pode esperar o ciclo normal de desenvolvimento, nem se pode misturar a correção com funcionalidades ainda não testadas. O hotfix é criado a partir da main, corrige o problema isoladamente, e ao final é mesclado (merge) tanto na main quanto na develop, garantindo que a correção esteja presente em ambos os fluxos. Isso preserva a integridade do histórico e evita que a correção fique presa a uma release que já foi publicada.

A pegadinha desta questão está em confundir o hotfix com outras branches do Gitflow. A banca explora o fato de o candidato não dominar o propósito de cada branch: a feature é para desenvolvimento de novas funcionalidades, a release é para preparar uma versão, e o hotfix é especificamente para correções urgentes em produção. A alternativa que menciona "criar uma branch a partir da develop" confunde o fluxo de correção com o fluxo de desenvolvimento normal, e a que menciona "release existente" ignora que uma release publicada não deve ser reutilizada para correções.

Guarde a fronteira entre as branches do Gitflow: feature parte da develop para novas funcionalidades, release parte da develop para preparar versão, e hotfix parte da main para correções urgentes. É exatamente nessa distinção que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Reescrever diretamente o histórico da main viola o princípio do Gitflow de que a main deve conter apenas código estável e testado. Reescrever histórico (por exemplo, com git rebase ou git reset) em uma branch compartilhada como a main é uma prática perigosa, pois quebra o repositório de quem já baixou o histórico anterior. A correção deve ser feita em uma branch separada (hotfix) e depois mesclada, nunca reescrevendo o histórico diretamente.

Alternativa B — ❌ Incorreta

Aguardar a próxima sprint para incluir o bug fix na develop é contrário ao propósito de uma correção crítica e urgente. O Gitflow prevê o hotfix exatamente para não depender do ciclo normal de desenvolvimento. Uma correção crítica em produção não pode esperar uma sprint; ela deve ser tratada imediatamente, isoladamente, e depois integrada.

Alternativa C — ❌ Incorreta

Criar uma branch a partir da develop para garantir que a feature vá para staging primeiro confunde o fluxo de correção com o fluxo de desenvolvimento de funcionalidades. A develop contém código em desenvolvimento, possivelmente instável, e não é o ponto de partida correto para uma correção crítica em produção. O hotfix deve partir da main, que representa o estado estável e publicado.

Alternativa D — ✅ Correta ⟵ GABARITO

Criar uma branch do tipo hotfix a partir da main é exatamente o procedimento correto no Gitflow para uma correção crítica e urgente em produção. O hotfix isola a correção, permite testá-la rapidamente e, ao final, é mesclado tanto na main quanto na develop, garantindo que a correção esteja disponível em ambos os fluxos sem arrastar mudanças não publicadas.

Alternativa E — ❌ Incorreta

Criar uma branch a partir da release existente, mesmo se esta já tiver sido publicada, é incorreto. Uma release publicada já foi mesclada na main e não deve ser reutilizada para correções. O hotfix deve partir da main, não de uma release antiga, pois a release representa um estado de preparação de versão, não o estado estável atual de produção.

Gabarito: letra D — a única alternativa que segue corretamente o fluxo do Gitflow para correções críticas em produção é criar uma branch do tipo hotfix a partir da main.