Questão de Engenharia de Software — Gerência de Configuração — FCC 2025
Engenharia de Software›Gerência de Configuração
Código
fc074735
Banca
FCC
Órgão
TRT - 15ª Região (SP)
Ano
2025
Nível
Superior
Cargo
Analista Judiciário - Área Apoio Especializado - Especialidade Tecnologia da Informação
A equipe de desenvolvimento de um Tribunal adota o modelo GiFlow para gerenciar o versionamento de código em um repositório GitLab. Durante o desenvolvimento de uma nova funcionalidade, a equipe percebeu que algumas mudanças feitas no branch feature impactam diretamente no branch develop e precisam ser incorporadas imediatamente para integração continua (Cl). Contudo, um dos desenvolvedores cometeu um erro ao realizar um merge, levando à sobrescrita de código existente no develop. O procedimento que a equipe deve adotar para resolver o problema de sobrescrita e prevenir a repetição desse erro no futuro é
Arealizar um git reset --hard no branch develop para voltar ao último commit correto e forçar os desenvolvedores a refazerem o merge.
Bconfigurar políticas de revisão opcionais (Operation Request Approvais) no Github para que todas as operações sejam aprovadas por, no mínimo, um revisor.
Cfazer um roliback do branch develop usando sit stepback, garantindo que apenas os commits problemáticos sejam desfeitos sem afetar o histórico.
Dconfigurar um Webhook no GitLab para rejeitar automaticamente merges que causam conflitos ou sobrescritas de código no develop.
Eutilizar a estratégia rebase no branch feature para reorganizar os commits e alinhar o histórico com o branch develop antes de realizar um novo merge.
Revelar gabarito e comentário▾
GabaritoE — utilizar a estratégia rebase no branch feature para reorganizar os commits e alinhar o histórico com o branch develop antes de realizar um novo merge.
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 – Correção de Merge Problemático
Gabarito: letra E. Para resolver a sobrescrita de código no branch develop e prevenir a repetição do erro, a equipe deve utilizar a estratégia rebase no branch feature, reorganizando os commits sobre o develop antes de realizar um novo merge. Isso alinha o histórico, evita conflitos e mantém a linearidade.
O GitFlow define branches feature, develop, release, hotfix e main. Quando um merge acidental sobrescreve código, a abordagem mais segura é reverter o merge (com git revert) e, em seguida, fazer rebase do feature sobre o develop atualizado, corrigindo conflitos passo a passo. Para o futuro, a equipe deve adotar práticas como rebase antes do merge e revisão obrigatória via Merge Request.
Alternativa A — ❌ Incorreta
git reset --hard remove commits do histórico, perdendo alterações legítimas. Além disso, forçar todos a refazerem o merge não previne o erro – é uma solução destrutiva e paliativa.
Alternativa B — ❌ Incorreta
Configurar políticas de revisão opcionais não impede o erro; sem obrigatoriedade, desenvolvedores podem ignorar. Além disso, o cenário usa GitLab, não GitHub, e a expressão “Operation Request Approvais” não corresponde a nenhum recurso padrão.
Alternativa C — ❌ Incorreta
O comando sit stepback não existe no Git. Rollback (revert) poderia desfazer os commits problemáticos, mas a descrição com termo fictício torna a alternativa inválida. Além disso, não previne ocorrências futuras.
Alternativa D — ❌ Incorreta
Webhooks no GitLab são notificações, não mecanismos de rejeição automática de merges. E mesmo que houvesse, não resolveria o merge já realizado; apenas bloquearia futuros merges com conflito, sem tratar a causa raiz (falta de rebase).
Alternativa E — ✅ Correta ⟵ GABARITO
Rebase do feature sobre o develop reescreve o histórico do feature para incluir as alterações mais recentes do develop. Isso permite resolver conflitos incrementalmente e evita que um merge cego sobrescreva mudanças. Após o rebase, o novo merge será limpo e linear, prevenindo o erro.
NÃO CAIA NESSA!
As alternativas C e D tentam confundir com termos inventados (sit stepback, webhook rejeitar merge) e soluções incompletas (reset destrutivo, revisões opcionais). O candidato deve reconhecer que rebase é a prática recomendada no GitFlow para integrar features de forma segura.