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

GitFlow: Integração de Feature na Develop

Gabarito: letra E. No GitFlow, a integração de uma branch de feature na develop é feita com git checkout develop && git merge feature/login-social — primeiro muda-se para a branch de destino (develop) e depois executa-se o merge da branch de origem (feature). Essa é a sequência canônica que preserva o histórico e registra o merge como etapa concluída do ciclo da feature.

O GitFlow é um modelo de ramificação (branching model) para Git, proposto por Vincent Driessen, que organiza o desenvolvimento em branches com papéis bem definidos: main (ou master) contém o código em produção; develop é a branch de integração, onde as funcionalidades são reunidas antes de um release; feature/* são branches criadas a partir de develop para desenvolver novas funcionalidades; release/* são criadas a partir de develop para preparar uma versão; e hotfix/* são criadas a partir de main para correções urgentes.

O fluxo de uma feature no GitFlow segue etapas sequenciais: (1) criar a branch feature/nome a partir de develop; (2) desenvolver e commitar na branch de feature; (3) integrar a feature de volta em develop — este é o passo que a questão cobra; (4) opcionalmente, deletar a branch de feature após a integração. A integração em si é feita com um merge da branch de feature na develop, e a prática recomendada é exatamente a sequência da alternativa E.

A distinção crucial que a banca explora é entre merge e rebase. O merge cria um novo commit de integração que preserva o histórico completo de ambas as branches, mantendo a rastreabilidade do que foi desenvolvido. O rebase, por outro lado, reescreve o histórico da branch de feature, aplicando seus commits por cima da develop, o que resulta em um histórico linear, mas reescreve os commits originais — algo perigoso se a branch já foi compartilhada com outros desenvolvedores. No GitFlow, a prática recomendada para integrar uma feature na develop é o merge, pois preserva o contexto da feature e evita reescrever histórico publicado.

Um exemplo concreto: imagine que a branch feature/login-social tenha 3 commits próprios. Ao executar git checkout develop && git merge feature/login-social, o Git cria um commit de merge na develop que aponta para os 3 commits da feature, preservando o histórico. Se usasse git rebase develop feature/login-social, os 3 commits seriam reaplicados sobre a develop, mas com novos hashes, e o histórico original seria perdido — o que quebraria o repositório de qualquer outro desenvolvedor que já tivesse baixado a branch.

A pegadinha desta questão está na ordem dos comandos e na confusão entre merge e rebase. O candidato pode ser tentado a escolher a alternativa D (git rebase develop feature/login-social), mas o rebase não é a prática recomendada no GitFlow para integrar features, pois reescreve o histórico. Também pode confundir a ordem dos argumentos no git merge — a alternativa C (git merge develop feature/login-social) está com a ordem invertida, o que tentaria integrar a develop na feature, não o contrário.

Guarde a fronteira entre merge (preserva histórico, cria commit de integração) e rebase (reescreve histórico, lineariza) — é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Esta alternativa apenas deleta a branch de feature e muda para a develop, sem integrar o código. O comando git branch -d feature/login-social tenta deletar a branch, mas o Git bloqueia a deleção se a branch não foi totalmente mesclada — e, mesmo que fosse possível, o código da feature não seria incorporado à develop. A ordem também está errada: primeiro deveria integrar, depois deletar. O erro específico é a ausência do merge, que é a etapa central da integração.

Alternativa B — ❌ Incorreta

O comando git pull origin develop --rebase feature/login-social mistura conceitos de forma incorreta. O git pull é usado para atualizar a branch atual com alterações do repositório remoto, e o --rebase reescreve o histórico local. Aqui, a sintaxe está errada: o git pull não aceita uma branch de feature como argumento dessa forma, e o rebase não é a prática recomendada no GitFlow para integrar features. O erro específico é a tentativa de usar pull --rebase para integrar, o que reescreveria o histórico e não criaria o commit de merge esperado.

Alternativa C — ❌ Incorreta

O comando git merge develop feature/login-social tem a ordem dos argumentos invertida. No Git, a sintaxe correta é git merge <branch-de-origem>, executado a partir da branch de destino. Aqui, o comando tenta mesclar a develop na feature, o que é o oposto do desejado. Além disso, não há checkout para a develop, então o merge seria executado na branch atual (feature), integrando a develop na feature — exatamente o contrário do que a questão pede. O erro específico é a inversão da ordem dos argumentos e a falta do checkout.

Alternativa D — ❌ Incorreta

O comando git rebase develop feature/login-social reescreve o histórico da branch de feature, aplicando seus commits por cima da develop. Embora isso resulte em um histórico linear, não é a prática recomendada no GitFlow para integrar features, pois reescreve os commits originais — o que é perigoso se a branch já foi compartilhada. Além disso, o rebase não cria um commit de merge, que é o que registra a integração como etapa concluída. O erro específico é a escolha do rebase em vez do merge, que viola a prática recomendada do GitFlow.

Alternativa E — ✅ Correta ⟵ GABARITO

Esta alternativa executa a sequência canônica: primeiro git checkout develop para mudar para a branch de destino, depois git merge feature/login-social para integrar a branch de feature. O merge cria um commit de integração que preserva o histórico completo da feature, registrando a etapa como concluída. Essa é exatamente a prática recomendada no GitFlow para integrar uma feature na develop.

Gabarito: letra E