Pular para o conteúdo principal

Questão de Engenharia de Software — Gerência de Configuração — FCC 2025

Engenharia de SoftwareGerência de Configuração
Código
fc074951
Banca
FCC
Órgão
TRT - 15ª Região (SP)
Ano
2025
Nível
Médio
Cargo
Técnico Judiciário - Área Apoio Especializado - Especialidade Tecnologia da Informação
Durante o desenvolvimento de um projeto colaborativo no GitHub, um Técnico da equipe realizou commits diretamente na branch principal (main) sem passar por uma revisão de código via Pull Request. A prática mais indicada para corrigir essa situação e minimizar o impacto na equipe:
  1. ACriar uma nova branch a partir do commit anterior às mudanças realizadas, mover os commits problemáticos para essa nova branch com o comando git cherry-pick e reverter os commits na branch principal.
  2. BExcluir os commits diretamente da branch principal com o comando git reset --hard HEAD--n e solicitar que todos os membros da equipe executem um git pull --force.
  3. CSolicitar que o desenvolvedor apague a branch principal do repositório remoto, recrie-a com a versão correta do código e envie as alterações novamente.
  4. DReverter os commits problemáticos utilizando o comando git reverse, criando commits inversos diretamente na branch principal para apagar as alterações indesejadas.
  5. EUtilizar o comando git undo --last-commits 3 para apagar os três últimos commits diretamente na branch principal, restaurando o estado anterior do código (podem ser apagados mais commits, se necessário).
Revelar gabarito e comentário

GabaritoA — Criar uma nova branch a partir do commit anterior às mudanças realizadas, mover os commits problemáticos para essa nova branch com o comando git cherry-pick e reverter os commits na branch principal.

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”.

Gerência de Configuração no Git: Corrigindo Commits Diretos na Branch Principal

Gabarito: letra A. A prática mais indicada é criar uma nova branch a partir do commit anterior, mover os commits problemáticos com git cherry-pick e reverter os commits na branch principal. Isso mantém o histórico limpo, preserva as alterações para revisão e minimiza o impacto na equipe.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa descreve o fluxo correto: criar uma branch no estado anterior, usar git cherry-pick para trazer os commits da main para essa branch, e então reverter os commits na main. Dessa forma, as alterações são preservadas para um Pull Request e a main permanece organizada.

Alternativa B — ❌ Incorreta

git reset --hard HEAD~n reescreve o histórico, e forçar um git pull --force em toda a equipe pode resultar em perda de trabalho local e desorganização do repositório compartilhado. Essa prática é desaconselhada em branches compartilhadas.

Alternativa C — ❌ Incorreta

Apagar e recriar a branch principal remotamente é uma medida drástica e desnecessária, causando grande impacto e confusão entre os membros da equipe.

Alternativa D — ❌ Incorreta

Não existe o comando git reverse; o correto seria git revert. Mesmo que fosse git revert, a abordagem de reverter diretamente na main não é a melhor porque as alterações não passariam por revisão antes de serem incorporadas.

Alternativa E — ❌ Incorreta

O comando git undo não faz parte do Git padrão. Além disso, apagar commits da main sem preservar as alterações para revisão não é uma boa prática.

NÃO CAIA NESSA!

A banca cria comandos fictícios como "git reverse" e "git undo" para testar se o candidato conhece os comandos reais do Git. Lembre-se: git revert cria commits inversos, e git cherry-pick aplica commits específicos em outra branch.

PEGA ESSA DICA!

Em Gerência de Configuração, nunca reescreva o histórico compartilhado. Prefira git revert para desfazer commits de forma segura, e git cherry-pick para mover commits para uma branch de revisão.

Link permanente: /questoes/fc074951