Quando se ouve a expressão Comandos Git que parecem trapaça, a primeira reação costuma ser ceticismo. Porém, basta ver um deles em ação para perceber como poucos caracteres no terminal podem eliminar horas de dor de cabeça e restaurar um projeto inteiro em questão de segundos.
Neste guia completo, vamos examinar sete comandos que, usados corretamente, dão a sensação de magia — mas que também carregam armadilhas capazes de prejudicar todo o histórico de um repositório. Entenda o que cada um faz, em que cenários eles salvam um dia de trabalho, e quando é melhor pisar no freio.
Por que esses comandos chamam tanta atenção
Git foi concebido para oferecer rastreabilidade granular e recuperação de alterações, mas grande parte das equipes limita o uso a add, commit, pull e push. À medida que a complexidade cresce, surgem situações em que comandos mais avançados se tornam essenciais: separar mudanças, corrigir mensagens de commit, desfazer resets equivocados ou limpar arquivos temporários. As sete instruções analisadas abaixo solucionam esses problemas numa velocidade que beira o inacreditável para quem nunca se aventurou além do básico.
git add -p: estágios seletivos a favor de commits limpos
O git add -p fragmenta cada arquivo modificado em blocos — os chamados hunks — e pergunta, um a um, se devem ou não ser enviados ao staging. Na prática, o recurso funciona como uma lista de verificação interativa que permite incluir apenas o que pertence logicamente ao commit atual, mantendo de fora trechos experimentais, prints de depuração ou mudanças que ainda não estão maduras.
Quando brilha: revisões de código ficam mais fáceis de entender, o histórico se torna didático e seu “eu do futuro” agradece por não precisar decifrar por que um simples ajuste visual vinha acompanhado de variáveis abandonadas.
Quando evitar: projetos com arquivos enormes gerados automaticamente, ou repositórios onde alterações linha a linha não fazem sentido (por exemplo, modelos binários), tornam a etapa interativa lenta e pouco proveitosa. Nesses casos, adicionar o arquivo inteiro pode ser mais eficiente.
git commit –amend: correção cirúrgica sem poluir o histórico
Errou a mensagem ou esqueceu um arquivo na hora do commit? O git commit –amend permite “voltar no tempo”, atualizar os arquivos em staging e reescrever o texto, substituindo o commit anterior pelo novo, como se o deslize nunca tivesse existido.
Quando brilha: elimina a necessidade de criar commits “typo fix” ou “add missing file”, mantendo a linha do tempo enxuta e profissional, algo especialmente útil antes de abrir um Pull Request para revisão.
Quando evitar: se o commit já foi publicado em um repositório compartilhado, reescrever o histórico obriga colegas a lidarem com divergências e force push. Só faça isso caso todos estejam cientes e confortáveis com o procedimento.
git reflog: a máquina do tempo que recupera o irrecuperável
Quase tudo em Git é reversível graças ao git reflog. Ele registra cada movimentação de ponteiro dos branches locais, permitindo recuperar referências perdidas após resets, rebases ou deleções acidentais.
Quando brilha: você executa um reset equivocado e percebe que horas de trabalho sumiram. Um simples git reflog revela o hash anterior e, com git checkout <hash>, tudo volta como estava.
Quando evitar: reflog não substitui backups; entradas antigas expiram, especialmente em clones rasos ou após coletas de lixo agressivas. Use-o como rede de segurança temporária, não como arquivo permanente.
git cherry-pick: transplante cirúrgico de commits
git cherry-pick aplica um commit específico em outro branch sem trazer o restante da linha do tempo original. É o equivalente a extrair apenas a correção de um recurso ainda inacabado para aplicar em produção.
Quando brilha: um “hotfix” já foi feito na branch de desenvolvimento, mas a entrega principal não está pronta. Cherry-pick permite levar a correção à branch estável sem antecipar código em progresso.
Quando evitar: uso frequente em branches de longa duração gera commits duplicados, novo hash e potenciais conflitos na hora de mesclar tudo. Reserve a técnica para exceções, não como fluxo diário.
git reset –hard: o botão “voltar ao zero”
git reset –hard descarta todas as alterações não registradas, redefine o diretório de trabalho e posiciona o branch no commit especificado. É o atalho mais rápido para eliminar experimentos fracassados e começar do zero.
Quando brilha: após um dia de protótipos não aproveitados, em vez de limpar arquivo por arquivo, um único comando devolve um repositório imaculado.
Imagem: Internet
Quando evitar: se existir algo ainda valioso no estado atual, salve primeiro em um stash. O hard reset não perdoa: o que estiver fora do controle de versão some definitivamente.
git clean -fd: a faxina que remove arquivos não rastreados
Projetos compilados geram binários, logs e artefatos intermediários que incham o diretório. O git clean -fd deleta tudo que não está versionado, restaurando o repositório ao retrato exato do último commit.
Quando brilha: resolve erros misteriosos provocados por construções antigas e libera espaço em disco, sendo mais rápido que rastrear extensões manualmente.
Quando evitar: diretórios contendo configurações locais ou chaves que propositalmente ficam fora do Git podem ser limpos por engano. Antes de executar, rode git clean -n para simular a ação e conferir o que seria apagado.
git rerere: memorização automática de conflitos
Com nome pitoresco de “reuse recorded resolution”, o comando permite que Git grave a forma como você solucionou um conflito e reproduza a mesma solução em mesclagens futuras que gerem o mesmo impasse.
Quando brilha: em branches de longa duração que passam por constantes rebases, o esforço de mesclar se reduz drasticamente. Depois de habilitar com git config rerere.enabled true e git config rerere.autoupdate true, resolver um conflito apenas uma vez é o suficiente para que as próximas ocorrências sejam automáticas.
Quando evitar: se a resolução depende de contexto em rápida mudança, Git pode aplicar uma correção obsoleta e introduzir bugs. Revise sempre o resultado de um rerere automático.
Orientações gerais para evitar riscos
O poder desses comandos se apoia em dois pilares: compreensão do histórico e cuidado ao trabalhar em equipe. Seguir boas práticas minimiza imprevistos:
1. Commits atômicos: mantenha alterações pequenas e coerentes; facilita uso de add -p e diminui a dependência de amend pós-commit.
2. Branches curtos: quanto menos tempo um branch vive isolado, menor o risco de conflitos e duplicações via cherry-pick.
3. Comunicação: combine antes de reescrever histórico público; um force push inesperado gera confusão e retrabalho.
4. Rotina de backup: reflog é eficaz, mas não eterno. Armazenar clones espelhados ou usar serviços de hospedagem com snapshots completa a estratégia.
Fluxo seguro para aplicar comandos avançados
1. Crie um branch de salvaguarda sempre que for usar reset –hard ou clean -fd. Um simples git branch backup-antes-do-reset garante ponto de retorno.
2. Use –dry-run onde houver suporte. Tanto clean quanto reset oferecem simulações que exibem o que será afetado.
3. Documente exceções. Se um arquivo não deve ser limpo, inclua no .gitignore para evitar surpresas.
4. Automatize testes. Antes de publicar mudanças reescritas via amend ou cherry-pick, rode a suíte de testes para garantir integridade.
Conclusão: dominar sem temer o Git
Os Comandos Git que parecem trapaça provam que o sistema de controle de versão vai muito além do “salvar estado” que a maioria imagina. Eles oferecem restauração instantânea, limpeza fulminante e edição cirúrgica do histórico. Contudo, a mesma força que impressiona pode demolir trabalho alheio se empregada sem análise.
A chave é cultivar repertório e discernimento: saber o que cada comando faz, quando ele resolve um problema real e por que em certos contextos é melhor resistir à tentação. Com prática, esses recursos deixam de soar como magia negra e passam a integrar um fluxo de desenvolvimento confiante, eficiente e reversível.
No fim das contas, Git é a prova de que o histórico não é algo que acontece com o desenvolvedor, mas sim uma narrativa que pode (e deve) ser escrita com cuidado. Usar bem essas sete instruções equivale a assumir a autoria dessa história, corrigindo, revisando e até reescrevendo capítulos inteiros quando necessário — sempre com responsabilidade.
Com informações de How-To Geek
