Questão de Engenharia de Software — Git — FCC 2026

Git: desfazendo alterações em branch pública

Gabarito: letra C. Quando um commit já foi publicado e compartilhado em uma branch pública (como a main), a recomendação é não reescrever o histórico — e sim criar um novo commit que desfaça as alterações do commit problemático, usando git revert. Isso preserva a integridade do histórico exigida pela auditoria e evita conflitos para quem já tem a versão antiga. As alternativas A, B e D reescrevem o histórico (com reset ou rebase + push --force), o que viola a exigência; a alternativa E, embora não reescreva o histórico, não desfaz o commit incorreto — apenas adiciona uma correção por cima, sem reverter o cálculo de ISS.

O Git é um sistema de controle de versão distribuído, que trata os dados como um conjunto de snapshots (imagens) do sistema de arquivos. Cada commit recebe um ID exclusivo (checksum SHA-1) e o histórico é imutável por padrão: o Git não remove dados, apenas adiciona novas versões. Essa característica é a base para entender por que reescrever um histórico já publicado é problemático.

Quando você reescreve o histórico de uma branch pública (com reset, rebase ou commit --amend), os hashes dos commits mudam. Qualquer pessoa que já tenha a versão antiga da branch (outro desenvolvedor, um servidor de CI/CD, um deploy) ficará com um histórico divergente — e o próximo git pull gerará conflitos ou exigirá push --force para sobrescrever o remoto. Em um ambiente de auditoria, isso é inaceitável: o histórico deve ser rastreável e íntegro.

O git revert resolve exatamente esse problema: ele cria um novo commit que aplica as alterações inversas ao commit especificado, sem apagar ou modificar o commit original. O histórico permanece linear e completo — o commit incorreto continua lá, mas com um commit posterior que o desfaz. Isso é a prática recomendada para branches públicas, conforme a documentação oficial do Git e as boas práticas de controle de versão.

Vamos comparar os comandos envolvidos:

A pegadinha da banca está em confundir "desfazer" com "reescrever". O enunciado exige que o histórico permaneça íntegro — ou seja, nada de reset, rebase ou push --force. A única alternativa que atende a isso e ainda desfaz o commit incorreto é o git revert.

Alternativa A — ❌ Incorreta

git reset --hard HEAD~1 remove o commit incorreto do histórico local e git push --force sobrescreve o histórico remoto. Isso reescreve o histórico já publicado, violando a exigência de integridade. Além disso, reset --hard descarta as alterações do commit, mas o commit continua existindo no reflog (até ser expirado) — e qualquer pessoa que já tenha a versão antiga terá conflito no próximo pull.

Alternativa B — ❌ Incorreta

git reset --soft HEAD~1 move o ponteiro da branch para o commit anterior, mantendo as alterações na staging area. Depois, ao criar um novo commit, o histórico é reescrito — o commit incorreto é removido e substituído por um novo. O git push --force final sobrescreve o remoto, o que viola a integridade do histórico. A intenção de "ajustar o código" é válida, mas a forma (reescrever) é proibida para branches públicas.

Alternativa C — ✅ Correta ⟵ GABARITO

git revert <hash_do_commit_incorreto> cria um novo commit que desfaz as alterações do commit especificado, sem modificar o histórico existente. O commit original permanece no histórico, e um novo commit é adicionado com as alterações inversas. Em seguida, git push origin main envia o novo commit para o remoto, sem reescrever nada. Isso atende perfeitamente às exigências: histórico íntegro, correção aplicada a partir do commit problemático, e sem --force.

Alternativa D — ❌ Incorreta

git rebase -i HEAD~2 abre o rebase interativo, permitindo excluir ou editar commits. Excluir a linha do commit incorreto reescreve o histórico — os commits seguintes são reaplicados com novos hashes. O git push --force-with-lease final sobrescreve o remoto, violando a integridade. O --force-with-lease é mais seguro que --force (verifica se o remoto não mudou), mas ainda assim reescreve o histórico — proibido no cenário.

Alternativa E — ❌ Incorreta

Esta alternativa não reescreve o histórico (o que é bom), mas também não desfaz o commit incorreto. Ela apenas adiciona um novo commit corretivo sobre o histórico atual, sem reverter o cálculo de ISS. O resultado é que o código fica corrigido, mas o histórico mantém o commit incorreto sem um commit de reversão explícito — o que pode confundir auditorias e dificultar o rastreamento. O git revert é a forma correta de desfazer, pois cria um commit que documenta claramente a reversão.

Gabarito: letra C