Alternativa correta: A

O tema central da questão é Gerência de Configuração, especificamente no contexto de controle de versões usando o Git, uma ferramenta essencial para o gerenciamento de código fonte e colaboração em projetos de software. O conhecimento sobre como manipular branches e commits é fundamental para garantir que o código seja desenvolvido de maneira organizada, colaborativa e com menos erros.

O problema apresentado é a realização de commits diretamente na branch principal sem revisão, o que é uma prática não recomendada por poder introduzir erros ou código não revisado no projeto principal. A prática mais indicada envolve técnicas para isolar, corrigir e rever alterações antes de integrá-las novamente à branch principal.

Vamos analisar a alternativa correta:

Justificativa da Alternativa A: Criar uma nova branch a partir do commit anterior às mudanças problemáticas e mover esses commits para essa nova branch usando o comando git cherry-pick é uma abordagem sensata. Isso permite que os commits sejam revisados e corrigidos antes de serem integrados novamente à branch principal. Além disso, reverter os commits problemáticos na branch principal garante que a versão principal do código continue estável. Essa abordagem minimiza o impacto na equipe e mantém um histórico limpo e organizado das alterações.

Análise das alternativas incorretas:

Alternativa B: Utilizar git reset --hard e forçar um git pull para toda a equipe pode causar perda de trabalho não salvo e inconsistências no repositório. É uma abordagem agressiva e arriscada, especialmente em ambientes colaborativos.

Alternativa C: Apagar a branch principal do repositório remoto é uma prática extremamente arriscada. Isso pode causar perda significativa de dados e interromper o trabalho de toda a equipe.

Alternativa D: O comando mencionado git reverse não é um comando válido no Git. O comando correto para reverter commits é git revert, mas aplicá-lo diretamente sem uma estratégia para revisão pode não ser a melhor abordagem.

Alternativa E: O comando git undo também não é um comando válido no Git. Além disso, apagar os últimos commits sem um processo de revisão pode resultar em perda de informações importantes.

Caso tenha dúvidas adicionais, é sempre recomendável consultar a documentação oficial do Git ou guias reconhecidos, como o Pro Git book disponível em git-scm.com.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

Alternativa A:

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.

Por que é a mais indicada:

Evita sobrescrever o histórico da branch main (evita reset --hard, push --force, etc).

Preserva os commits feitos, caso algo seja aproveitável (salva-os em outra branch).

Permite reversão limpa na main com git revert, sem risco de quebrar o trabalho dos colegas.

Boa prática colaborativa, sem impacto no histórico remoto da equipe.

Por que as outras estão incorretas ou perigosas:

B) reset --hard + pull --force:

Sobrescreve o histórico, afeta o repositório de todos.

Exige que todos os membros façam git pull --force, o que é arriscado e desaconselhado.

C) Apagar a main e recriar:

Extremamente drástico e perigoso.

Quebra o versionamento, pipelines e histórico.

Pode causar confusão na equipe e perda de dados.

D) Usar git reverse (provavelmente quis dizer git revert):

Parece uma boa opção, mas não salva os commits em outro lugar.

Pode ser usada em conjunto com a opção A (mas isoladamente não resolve a parte de preservar o que foi feito).

E) git undo --last-commits:

Esse comando não existe no Git. Parece ser uma suposição ou erro conceitual.

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

Essa prática:

• Preserva o histórico da branch principal.
• Evita perda de trabalho (os commits são reaproveitados).
• Permite aplicar revisão posterior via Pull Request na nova branch.
• Reverte as alterações indesejadas na main, mantendo a integridade da branch principal para os demais membros da equipe.
• Não obriga ninguém a usar git pull --force, o que é perigoso em ambientes colaborativos.

A alternativa A está correta e representa a prática mais indicada. Criar uma nova branch a partir do commit anterior às mudanças problemáticas permite isolar os commits indesejados. Em seguida, usando o comando git cherry-pick, os commits que realmente devem ser mantidos podem ser movidos para essa nova branch. Por fim, os commits problemáticos são revertidos na branch principal, mantendo o histórico limpo e preservando o trabalho válido. Essa abordagem evita reescrever o histórico compartilhado, o que poderia causar conflitos para outros colaboradores.

A alternativa B, que sugere usar git reset --hard seguido de um push forçado, é arriscada, pois reescrever o histórico da branch principal pode causar problemas para todos que já sincronizaram o repositório, exigindo que eles façam correções manuais complexas.

A alternativa C, apagar e recriar a branch principal no remoto, é uma ação drástica que pode causar perda de histórico e confusão para a equipe, além de ser pouco prática e insegura.

A alternativa D menciona o comando git reverse, que não existe no Git. O comando correto para desfazer commits criando novos commits inversos é git revert, mas essa alternativa não detalha o processo completo para lidar com múltiplos commits problemáticos.

A alternativa E cita um comando inexistente (git undo), portanto está incorreta.

Portanto, a melhor prática para corrigir commits feitos diretamente na branch principal sem revisão é a descrita na alternativa A.

Resposta: A - Perplexity

--------------

Comentário adicional

Quando um desenvolvedor realiza commits diretamente na branch principal sem passar pelo fluxo de revisão por Pull Request, a prática mais comum e recomendada é reverter esses commits na própria branch principal utilizando o comando git revert, que cria novos commits inversos para desfazer as alterações indesejadas sem reescrever o histórico compartilhado. Em seguida, os commits que precisam ser revisados podem ser isolados em uma nova branch criada a partir do ponto anterior às alterações, utilizando comandos como git cherry-pick para transferir apenas as mudanças relevantes. Essa abordagem preserva o histórico do projeto, evita conflitos para outros colaboradores e mantém o fluxo de revisão e colaboração organizado. Além disso, é importante reforçar com a equipe a adoção de boas práticas, como o uso consistente de branches para novas funcionalidades e correções, mensagens de commit claras e a obrigatoriedade de Pull Requests para qualquer alteração na branch principal, garantindo assim a qualidade e a rastreabilidade do código no repositório.