Questão de TI - Desenvolvimento de Sistemas — Outros Tópicos de Desenvolvimento de Sistemas — Quadrix 2025

Git: branches, commit e correção de erros

Gabarito: letra B. O analista deveria ter criado uma branch separada (git checkout -b feature/renovação) antes de desenvolver a nova funcionalidade, seguindo o fluxo de trabalho com branches que isola o desenvolvimento e evita que alterações instáveis cheguem à main. As demais alternativas contêm erros conceituais sobre comandos Git: git pull não corrige erro de commit, git revert não remove o commit (cria um novo commit reverso), git reset --soft não altera o repositório remoto, e git stash não é usado após o commit.

O Git é um sistema de controle de versão distribuído que permite gerenciar o histórico de alterações de um projeto. Uma das práticas mais importantes é o uso de branches (ramificações): linhas independentes de desenvolvimento que partem de um ponto comum do histórico. Ao criar uma branch para desenvolver uma nova funcionalidade, o analista isola suas alterações da main (a branch principal, geralmente a versão estável do projeto). Somente após testar e validar a funcionalidade, ele faria o merge (integração) da branch de volta à main. Essa prática é essencial em equipes e até mesmo em projetos individuais, pois evita que código instável ou incompleto afete a versão principal.

No caso narrado, o analista cometeu dois erros: (1) desenvolveu a feature diretamente na main, sem criar uma branch separada; e (2) fez o commit direto na main, desestabilizando o sistema. A alternativa B aponta exatamente a solução preventiva: criar uma branch feature/renovação antes de desenvolver, isolando o trabalho. Essa é a prática recomendada em fluxos como Git Flow e GitHub Flow, onde a main deve permanecer sempre estável e pronta para deploy.

Para entender por que as outras alternativas estão erradas, é preciso dominar o que cada comando faz:

• git pull: busca e integra alterações do repositório remoto ao local. Não corrige um commit que já foi feito; apenas atualiza o código local com o que está no remoto.

• git revert: cria um novo commit que desfaz as alterações de um commit anterior, preservando o histórico. Não "remove" o commit; ele adiciona um commit reverso.

• git reset --soft: move o ponteiro da branch para um commit anterior, mantendo as alterações na área de staging. Não altera o repositório remoto; apenas o histórico local.

• git stash: guarda temporariamente alterações não commitadas, permitindo que o desenvolvedor mude de branch ou faça outras operações. Não é usado após o commit, pois o commit já registrou as mudanças.

A pegadinha da banca está em confundir o propósito de cada comando, especialmente git revert e git reset. O candidato que não domina a diferença entre "desfazer" (revert) e "remover" (reset) pode cair na alternativa C. Além disso, a alternativa D mistura conceitos de histórico local e remoto, afirmando que o reset --soft remove o commit do histórico remoto, o que é falso.

Guarde a distinção central: branches isolam o desenvolvimento (prevenção) e revert/reset corrigem erros (reação). A questão cobra a prática preventiva, que é a alternativa B.

Alternativa A — ❌ Incorreta

O comando git pull sincroniza o repositório local com o remoto, baixando e integrando alterações. No cenário, o erro já foi cometido (commit na main), e o git pull não corrige o problema — ele apenas atualiza o código local com o que está no remoto. A alternativa sugere uma ação que não resolve a instabilidade causada pelo commit. O correto seria reverter ou resetar o commit, ou, preventivamente, ter usado uma branch.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa B está correta porque descreve a prática recomendada de desenvolvimento: criar uma branch separada (git checkout -b feature/renovação) antes de desenvolver a nova funcionalidade. Isso isola as alterações da main, evitando que código instável ou incompleto afete a versão principal. Após validar a feature, o analista faria o merge de volta à main. Essa é a essência do fluxo de trabalho com branches, amplamente adotado em equipes de desenvolvimento.

Alternativa C — ❌ Incorreta

O comando git revert HEAD cria um novo commit que desfaz as alterações do commit anterior, preservando o histórico. Ele não "remove" o commit; adiciona um commit reverso. A alternativa afirma que o comando "remove o commit anterior sem afetar o histórico", o que é contraditório: o revert preserva o histórico justamente por criar um novo commit. O erro está em descrever o revert como uma remoção, quando na verdade é uma reversão.

Alternativa D — ❌ Incorreta

O comando git reset --soft HEAD~1 move o ponteiro da branch para o commit anterior, mantendo as alterações na área de staging. Ele não remove o commit do histórico remoto — na verdade, o reset só afeta o histórico local, e o repositório remoto permanece inalterado até que um git push --force seja executado. A alternativa mistura conceitos: o reset --soft não altera o remoto, e o histórico local é modificado, não o remoto.

Alternativa E — ❌ Incorreta

O comando git stash é usado para guardar temporariamente alterações não commitadas, permitindo que o desenvolvedor mude de branch ou faça outras operações. Após o commit, as alterações já foram registradas no histórico, e o stash não é aplicável — ele só funciona com mudanças não commitadas. A alternativa sugere usar o stash após o commit, o que é conceitualmente incorreto.

Gabarito: letra B