Questão de Engenharia de Software — Github e Gitlab — FCC 2025

Controle de Versão: corrigindo commits diretos na branch principal

Gabarito: letra C. A prática mais indicada é criar uma nova branch a partir do commit anterior às mudanças, mover os commits problemáticos para essa nova branch com git cherry-pick e reverter os commits na branch principal — isso preserva o histórico, evita reescrita de histórico compartilhado e mantém a integridade do repositório para toda a equipe.

O cenário descrito é clássico em equipes que adotam Git: um desenvolvedor fez commits diretamente na branch principal (main), pulando o fluxo de revisão via Pull Request. O problema não é apenas o código em si, mas o histórico compartilhado — a branch principal é usada por todos, e qualquer operação que reescreva esse histórico (como reset --hard ou rebase) quebra o repositório local de quem já baixou os commits. Por isso, a solução correta precisa preservar o histórico e mover as alterações para um contexto onde possam ser revisadas.

O Git é um sistema de controle de versão distribuído: cada desenvolvedor tem uma cópia completa do repositório, e os commits são identificados por um hash SHA-1 único. Quando você reescreve um commit já publicado, o hash muda, e quem tinha a versão antiga fica com um histórico divergente — o git pull falha com conflitos. É por isso que a regra de ouro é: nunca reescreva histórico que já foi compartilhado.

A alternativa C resolve o problema em três passos seguros:

1. Criar uma nova branch a partir do commit anterior às mudanças problemáticas — isso isola o trabalho em um ramo separado, sem tocar na main.

2. Mover os commits para a nova branch com git cherry-pick — o comando aplica os commits selecionados em outra branch, copiando as alterações sem apagar o original.

3. Reverter os commits na branch principal com git revert — cria commits inversos que desfazem as alterações, preservando o histórico (não apaga nada, apenas adiciona novos commits que anulam os anteriores).

Esse fluxo mantém a main íntegra, permite que a equipe revise o código na nova branch via Pull Request e, depois da aprovação, faça o merge normalmente. As demais alternativas falham por usarem comandos inexistentes, reescreverem histórico compartilhado ou proporem soluções drásticas e desnecessárias.

A pegadinha central desta questão é a distinção entre reverter e reescrever: git revert cria commits inversos (seguro, preserva histórico), enquanto git reset --hard apaga commits (perigoso, reescreve histórico). A banca explora exatamente essa confusão, oferecendo alternativas que parecem plausíveis mas violam a regra de não reescrever histórico compartilhado.

Guarde o critério decisivo: em branch compartilhada, nunca reescreva histórico — sempre reverta ou mova os commits. É essa fronteira que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

O comando git reverse não existe no Git. O comando correto para desfazer alterações criando commits inversos é git revert, não git reverse. Além disso, a alternativa sugere "apagar as alterações indesejadas" diretamente na branch principal, o que contraria a boa prática de preservar o histórico. A banca troca o nome do comando para testar se o candidato conhece a sintaxe real do Git.

Alternativa B — ❌ Incorreta

O comando git undo --last-commits 3 não existe no Git. Não há um comando undo nativo; as operações de desfazer são feitas com git reset, git revert ou git checkout. Além disso, apagar commits diretamente na branch principal reescreve o histórico compartilhado, o que quebra o repositório dos demais membros da equipe. A alternativa mistura comandos fictícios com uma prática perigosa.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta é a prática mais indicada. Criar uma nova branch a partir do commit anterior isola as mudanças; git cherry-pick move os commits para a nova branch sem apagar o original; e git revert na branch principal cria commits inversos, desfazendo as alterações sem reescrever o histórico. Esse fluxo preserva a integridade do repositório, permite revisão via Pull Request e minimiza o impacto na equipe. É exatamente o que a alternativa descreve.

Alternativa D — ❌ Incorreta

O comando git reset --hard HEAD--n está malformado (o correto seria HEAD~n ou HEAD^n), e a prática de apagar commits diretamente da branch principal reescreve o histórico compartilhado. Pior: solicitar que todos executem git pull --force (que também não é um comando válido — o correto seria git pull --force ou git fetch --force) força a sobrescrita do histórico local de todos, causando perda de trabalho e conflitos. Essa é a alternativa mais perigosa, pois propaga o erro para toda a equipe.

Alternativa E — ❌ Incorreta

Apagar a branch principal do repositório remoto e recriá-la é uma solução drástica e desnecessária. Isso interrompe o trabalho de toda a equipe, pode causar perda de commits não sincronizados e não resolve o problema de forma cirúrgica. Além disso, não há garantia de que a "versão correta do código" esteja disponível em algum lugar — a abordagem correta é preservar o histórico e mover os commits, não destruir a branch.

Gabarito: letra C — a única alternativa que preserva o histórico, isola as mudanças para revisão e minimiza o impacto na equipe.