Questão de Engenharia de Software — Gerência de Configuração — FCC 2026
Engenharia de Software›Gerência de Configuração
Código
gp044441
Banca
FCC
Órgão
MPE-AL
Ano
2026
Cargo
Analista do Ministério Público - Especialidade: Desenvolvimento de Sistemas
Em uma equipe de desenvolvimento que adota o modelo GitFlow para organização do versionamento, o desenvolvedor finalizou a implementação de uma nova funcionalidade na branch feature/login-social, criada a partir da branch develop. Após a conclusão dos testes locais e validação do código, ele precisa reintegrar essa funcionalidade ao fluxo principal de desenvolvimento, garantindo que a branch de origem permaneça corretamente identificada. Sendo o merge com etapa concluída do ciclo da feature. Nessa situação, a ação correta para realizar a integração conforme a prática recomendada do GitFlow é
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 Branch
Gabarito: letra E. No GitFlow, uma feature branch (criada a partir de develop) deve ser integrada de volta à develop por meio de um merge. A sequência correta é: primeiro fazer checkout para develop, depois executar o merge da feature branch. É exatamente o que a alternativa E faz (git checkout develop && git merge feature/login-social).
A banca testa o conhecimento do fluxo padrão do GitFlow, onde as funcionalidades são desenvolvidas em branches separadas e, ao final, mescladas na branch develop – nunca diretamente na main ou master. As demais alternativas apresentam comandos com branches erradas ou operações inadequadas.
Alternativa A — ❌ Incorreta
git branch -d feature/login-social && git checkout develop Deleta a feature branch antes de fazer checkout para develop, sem ter integrado as alterações. O merge deve ocorrer antes da deleção. Além disso, a ordem está invertida.
Alternativa B — ❌ Incorreta
git pull origin develop --rebase feature/login-social O comando é confuso: --rebase é uma flag do git pull, mas a sintaxe git pull origin develop --rebase feature/login-social não faz sentido no Git. O rebase não é a prática recomendada no GitFlow para finalizar uma feature; o merge é preferido para preservar o histórico.
Alternativa C — ❌ Incorreta
git merge develop feature/login-social A sintaxe git merge <branch-destino> <branch-origem> está errada. No Git, o merge é feito estando na branch que receberá as alterações: git checkout develop e depois git merge feature/login-social. Aqui, a ordem dos argumentos está trocada.
Alternativa D — ❌ Incorreta
git rebase develop feature/login-social O rebase reescreve o histórico, o que não é recomendado no GitFlow para branches compartilhadas. O merge preserva a estrutura e é o padrão para finalizar features. Além disso, se executado, traria os commits da develop para a feature branch, e não o contrário.
Alternativa E — ✅ Correta ⟵ GABARITO
git checkout develop && git merge feature/login-social Sequência clássica do GitFlow: posiciona-se na branch develop (destino) e mescla a feature branch nela. Após o merge bem-sucedido, a feature branch pode ser deletada. Essa é a prática recomendada.
NÃO CAIA NESSA!
A banca explora a confusão entre branches alvo (develop vs. main) e entre comandos (merge vs. rebase). No GitFlow, a feature sempre retorna para develop, e o merge é a operação padrão. O rebase pode ser usado, mas não é a prática estabelecida para finalização.
flowchart LR
A[develop] --> B[feature/login-social]
B --> C{merge feature/login-social into develop}
C --> D[develop atualizada]
D --> E[main (via release)]