Questão de Engenharia de Software — Geral — FCC 2026
Engenharia de Software›Geral
Código
fc142096
Banca
FCC
Órgão
MPE SE
Ano
2026
Cargo
Ana ( )
Uma analista criou a branch feature/login a partir de develop. Enquanto ela trabalha, outros commits entram em develop.
Quando terminar, a analista precisa integrar sua feature no fluxo GitFlow.
O procedimento que a analista tem que seguir é:
AFinalizar a feature fazendo merge primeiro em main e, em seguida, trazer esse merge de volta para develop.
BFazer merge periódico de develop em feature/login; quando a feature estiver concluída, mesclar feature/login de volta em develop.
CCriar feature/login a partir de main e, ao concluir, mesclar direto em main, sem passar por develop.
DUsar git rebase main sempre que houver novos commits e depois fazer merge de feature/login diretamente em main.
ENão atualizar a branch durante o desenvolvimento e só no final usar merge --squash para juntar tudo em main.
Revelar gabarito e comentário▾
GabaritoB — Fazer merge periódico de develop em feature/login; quando a feature estiver concluída, mesclar feature/login de volta em develop.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
GitFlow: Integração de Feature Branches
Gabarito: letra B. No GitFlow, a branch feature/login deve ser criada a partir de develop e, ao longo do desenvolvimento, deve receber merges periódicos de develop para se manter atualizada; ao concluir, a feature é mesclada de volta em develop. Esse é o fluxo canônico do modelo, que isola o trabalho em andamento e garante que a integração aconteça na branch de desenvolvimento, antes de qualquer release.
O GitFlow é um modelo de ramificação (branching model) criado por Vincent Driessen, amplamente adotado em equipes que precisam conciliar desenvolvimento contínuo com releases versionadas. Ele organiza o repositório em branches com papéis bem definidos: main (ou master) guarda apenas o código estável e pronto para produção; develop é a branch de integração, onde o trabalho das features é consolidado; feature/* são branches temporárias criadas a partir de develop para desenvolver uma funcionalidade isolada; release/* preparam a próxima versão; e hotfix/* corrigem problemas urgentes em produção.
A lógica central do modelo é que toda feature nasce de develop e morre em develop. Durante o desenvolvimento, é recomendado integrar as mudanças de develop na branch da feature (merge ou rebase) para minimizar conflitos e garantir que a feature continue compatível com o que já foi integrado. Ao finalizar, a feature é mesclada de volta em develop, e só depois, quando houver uma release, develop é mesclada em main. Isso mantém main sempre estável e permite que várias features sejam desenvolvidas em paralelo sem se pisarem.
A alternativa B descreve exatamente esse fluxo: merge periódico de develop em feature/login (manter a feature atualizada) e, ao concluir, merge de feature/login de volta em develop (integrar a feature). As demais alternativas distorcem o modelo, seja invertendo a ordem das branches, ignorando develop ou usando práticas que não são as recomendadas pelo GitFlow.
O ponto que separa as alternativas é a hierarquia das branches: no GitFlow, develop é o ponto de integração intermediário obrigatório entre as features e main. Qualquer alternativa que pule develop (indo direto para main) ou que crie a feature a partir de main está fora do modelo. Guarde essa fronteira: feature → develop → release → main.
Alternativa A — ❌ Incorreta
Faz o merge da feature diretamente em main e depois traz de volta para develop. Isso inverte a hierarquia do GitFlow: a feature deve ser integrada primeiro em develop, e main só recebe código via release ou hotfix. Mesclar direto em main quebra a estabilidade da branch principal e foge completamente do modelo.
Alternativa B — ✅ Correta ⟵ GABARITO
Descreve o fluxo GitFlow canônico: manter a feature atualizada com merges periódicos de develop (evitando conflitos grandes no final) e, ao concluir, mesclar a feature de volta em develop. É exatamente o que o modelo prescreve para branches feature/*.
Alternativa C — ❌ Incorreta
Cria a feature a partir de main e mescla direto em main, sem passar por develop. No GitFlow, features são criadas a partir de develop, não de main. A branch main é reservada para código estável e releases; integrar features diretamente nela viola o propósito do modelo.
Alternativa D — ❌ Incorreta
Sugere usar git rebase main e depois mesclar a feature diretamente em main. Além de ignorar develop (o ponto de integração central do GitFlow), o rebase contra main não é a prática recomendada para features — o correto é integrar com develop. O rebase pode até ser usado para atualizar a feature, mas contra develop, não contra main.
Alternativa E — ❌ Incorreta
Propõe não atualizar a branch durante o desenvolvimento e usar merge --squash direto em main no final. Isso contraria o GitFlow em dois pontos: (1) a feature deve ser atualizada periodicamente com develop para evitar conflitos; (2) a integração final é em develop, não em main. O merge --squash é uma técnica válida em outros contextos, mas não é o procedimento padrão do GitFlow.