Até agora consideramos um cenário ideal: você escreve código, faz commits e cria um Pull Request. Mas, na vida real, muitas vezes algo dá errado: você pode cometer um erro no código, fazer um commit com uma mensagem incorreta ou simplesmente perceber que seguiu na direção errada. Nesta aula, veremos como resolver os problemas mais comuns.
1. Rollback — desfazer alterações antes do commit
Cenário: você alterou um arquivo, mas percebeu que todas as suas mudanças estão erradas e quer rapidamente voltar o arquivo ao estado em que estava após o último commit.
Use a função Rollback:
- Abra a aba
Commit. - Encontre na lista o arquivo modificado que você quer “reverter”.
- Clique nele com o botão direito e escolha
Rollback.
A IDE avisará que as alterações serão perdidas. Confirme, e o arquivo voltará imediatamente à sua última versão salva no Git. Essa é a forma mais simples e segura de desfazer alterações locais.
2. Reset — remoção de commits locais
Cenário: você fez um ou mais commits, mas ainda não fez push. Você percebeu que esses commits estão errados e quer removê-los completamente, como se nunca tivessem existido.
Use a função Reset:
- Abra a aba
Git -> Logpara ver o histórico de commits. - Encontre o último commit “bom” em que você quer ficar (aquele que veio antes dos commits com erro).
- Clique nele com o botão direito e escolha
Reset Current Branch to Here....
Na janela que abrir, você poderá escolher o modo de reset. O mais drástico é o Hard.
Atenção! O modo Hard exclui de forma irreversível todos os commits após o selecionado, bem como todas as alterações de código contidas neles. Use com muito cuidado e somente para commits que ninguém viu ainda (aqueles que não foram enviados ao GitHub).
3. O que fazer depois de Push?
Cenário: você fez push e só depois percebeu um erro nele.
Assim que o commit chega ao servidor remoto, ele passa a fazer parte do histórico compartilhado do projeto. Tentar reescrever esse histórico pode criar enormes problemas para seus colegas. Imagine que eles já baixaram suas alterações e começaram seu trabalho com base nelas.
Solução correta e segura:
Basta fazer um novo commit que corrija o erro e enviá-lo. Isso é uma prática absolutamente normal. Assim, o histórico permanece honesto e claro para todos.
4. Olhando para o passado: trabalho avançado com o log
Já conhecemos a aba Git -> Log, mas ela não é apenas uma lista de commits — é uma ferramenta poderosa de investigação.
- Hash do commit (Commit Hash): você provavelmente notou no log uma sequência de letras e números, por exemplo
a1b2c3d. Esse hash é único; ele permite referenciar com precisão qualquer ponto na história do projeto. Raramente você terá que usá-lo manualmente, mas é importante saber que ele é o identificador único de cada “instantâneo” do seu código.![]()
- Você pode filtrar o histórico por branch, autor, data ou até por palavra na mensagem do commit. Isso ajuda a encontrar rapidamente quem trabalhou e quando em uma parte específica da funcionalidade.
- Quer encontrar o commit em que uma linha específica de código foi adicionada ou removida? Na janela
Loghá um campo de busca que pesquisa não só nas mensagens, mas também no conteúdo das próprias mudanças. - Clique com o botão direito nas margens do editor de código e escolha
Annotate with Git Blame. A IDE mostrará ao lado de cada linha quem a alterou pela última vez e em qual commit. Isso é incrivelmente útil para entender por que o código está escrito desse jeito.
5. Zona perigosa: Force Push
Já estabelecemos que alterar commits enviados é uma má ideia. Mas e se você alterou seu histórico local (por exemplo, com Reset) e agora ele diverge do histórico no servidor? Ao tentar fazer um push normal, o Git emitirá um erro, protegendo o histórico compartilhado contra reescrita.
Para esses casos existe a opção — force push (envio forçado). Esse comando diz ao servidor: “Esqueça tudo o que você tinha. Minha versão local do histórico é a única correta. Substitua o seu histórico pelo meu”.
ATENÇÃO! Em 99 % dos casos, usar force push em projetos de equipe é uma catástrofe. Isso pode apagar irreversivelmente commits que seus colegas já baixaram e nos quais estão baseando seu trabalho. É como arrancar páginas de um livro da biblioteca compartilhada e colar as suas no lugar.
Quando é terminantemente PROIBIDO usar force push:
- Em qualquer branch compartilhada:
main,develop,master. Nunca. - Em qualquer branch em que alguém além de você esteja trabalhando.
O único cenário aceitável:
Você está trabalhando na sua branch pessoal de feature, que ninguém viu nem usou ainda. Você fez alguns commits “sujos”, enviou-os ao servidor e depois decidiu “dar uma ajeitada” neles usando Reset. Nesse caso, você pode fazer force push para atualizar sua branch no servidor antes de criar o Pull Request.
Na IDE essa opção normalmente fica atrás do botão Push. Os desenvolvedores da IDE fizeram isso de propósito para evitar cliques acidentais.
Se você não tiver 100 % de certeza do que está fazendo, nunca use force push. É mais seguro criar um novo commit com as correções.
6. Atualização do projeto
Sempre clique em Update Project na branch main antes de começar a trabalhar em uma nova tarefa. Isso vai poupá-lo de muitos conflitos de merge futuros e garante que você comece a trabalhar com a versão mais atual do código.
GO TO FULL VERSION