Questão de Tecnologia da Informação · FCC TRT15 2024 (nº 35)

Quando se trabalha em equipe com Git, a branch principal (como main ou master) deve ser sempre estável e ter um histórico limpo. Fazer commits diretos nela sem revisão é um erro, e a correção ideal envolve remover esses commits da main de forma segura, sem apagar o trabalho e permitindo que ele seja revisado depois.

• (A) Correta: Esta é a solução mais segura e recomendada. Primeiro, você cria uma nova branch a partir do ponto antes dos commits problemáticos. Em seguida, usa git cherry-pick para "copiar" esses commits para a nova branch, preservando o trabalho. Finalmente, git revert é usado na branch principal para criar novos commits que desfazem as alterações dos commits problemáticos, mantendo o histórico da main linear e sem reescrevê-lo, o que é crucial para branches compartilhadas. O trabalho agora está na nova branch, pronto para um Pull Request e revisão adequada.
• (B) Incorreta: O comando git reset --hard reescreve o histórico, o que é extremamente perigoso em branches compartilhadas. Se outros membros da equipe já puxaram esses commits, um git pull --force pode causar perda de trabalho local ou conflitos complexos para eles, pois força a atualização da branch local para corresponder à remota, descartando alterações não sincronizadas. Armadilha da banca: git reset --hard parece uma solução rápida para "apagar" commits, mas ignora as consequências devastadoras para a colaboração.
• (C) Incorreta: Apagar a branch principal (main) de um repositório remoto é uma ação drástica e desnecessária que causaria grande interrupção para toda a equipe, exigindo que todos reconfigurassem seus repositórios locais.
• (D) Incorreta: Embora git revert seja a forma correta de desfazer commits em uma branch compartilhada sem reescrever o histórico, esta alternativa apenas reverte os commits. Ela não oferece uma maneira de preservar o trabalho para futura revisão em uma nova branch, o que é um objetivo importante ao corrigir a situação. A solução completa deve preservar o trabalho para que ele possa ser integrado corretamente depois.
• (E) Incorreta: git undo não é um comando Git padrão. Além disso, "apagar commits diretamente" geralmente implica reescrever o histórico, o que é problemático em branches compartilhadas.