13 comandos git avançado que todo dev deveria dominar

Você domina git add, commit e push, mas o histórico do projeto ainda parece um novelo. O git avançado não é sobre decorar sintaxe: é sobre ter controle cirúrgico do que acontece com cada commit. Neste guia, organizamos 13 comandos que separam quem apenas usa git de quem realmente entende o fluxo. Vamos na ordem de impacto no dia a dia, do mais útil ao mais específico.

1. git rebase -i (interativo)

O rebase -i permite reescrever o histórico: combinar commits, editar mensagens, reordenar ou descartar mudanças. Em vez de poluir a branch com 15 commits de "ajuste", você condensa em um único commit limpo antes do merge. Use git rebase -i HEAD~3 para interagir com os últimos 3 commits. Atenção: nunca rebaseie commits já enviados para uma branch compartilhada.

2. git cherry-pick

Precisa aplicar um commit específico de outra branch sem trazer tudo? git cherry-pick <hash-do-commit> faz exatamente isso. É o comando ideal para hotfixes em produção: a correção foi feita na develop, mas a main precisa dela agora. Um critério: se você usa cherry-pick com frequência, reavalie a estratégia de branching, talvez o fluxo esteja fragmentado.

3. git bisect

Encontrar qual commit introduziu um bug pode ser um pesadelo. O git bisect faz uma busca binária automática: você marca um commit bom e um ruim, e ele testa os intermediários até isolar o culpado. Em um projeto com 100 commits, o bisect reduz a busca a 7 testes. Sem ele, você revisaria manualmente cada mudança.

4. git stash

Mudanças no meio do caminho e precisa trocar de branch? git stash guarda o trabalho temporariamente e git stash pop o restaura. O comando aceita -u para incluir arquivos não rastreados. Um detalhe que poucos usam: git stash show -p exibe o diff guardado antes de aplicar, evitando surpresas.

5. git reflog

O reflog é o seguro de vida do git. Ele registra cada movimento do HEAD, incluindo resets e rebases. Se você perdeu commits num reset --hard, git reflog mostra o hash antigo e git reset --hard <hash> recupera tudo. Em equipes, ensinar reflog evita o pânico de "deletar a branch sem querer".

6. git log --graph --oneline --all

Visualizar o histórico como um grafo ASCII revela como as branches se entrelaçam. Com --graph, você enxerga merges, rebases e bifurcações. Adicione --decorate para ver apontadores de branches e tags. É o comando que mais ajuda em code review: antes de aprovar, veja o caminho real do código.

7. git diff --staged

Antes de commitar, revise exatamente o que vai entrar. git diff --staged mostra as mudanças já adicionadas à staging area, separando-as das alterações soltas. Um critério: se o diff staged inclui mudanças não relacionadas, quebre em commits menores. Isso facilita o bisect e o revert futuro.

8. git reset --soft e --hard

O reset volta o estado do repositório: --soft desfaz o commit mantendo as mudanças na staging, --mixed (padrão) mantém no working directory, e --hard descarta tudo. Use --soft para corrigir a mensagem do último commit ou combinar commits. Use --hard somente quando tiver certeza: ele apaga mudanças não commitadas permanentemente.

9. git revert

Diferente do reset, o revert cria um novo commit que desfaz as mudanças de um commit anterior. Isso preserva o histórico e é seguro para branches compartilhadas. Em produção, o revert é a escolha padrão: se um commit quebrou algo, desfaça-o sem reescrever o que os outros já puxaram.

10. git tag

Tags marcam pontos específicos do histórico, normalmente versões de release. git tag -a v1.0 -m "release" cria uma tag anotada, e git push --tags a envia. Em times que fazem deploy por tag, isso garante rastreabilidade: cada versão tem um hash imutável.

11. git clean

Arquivos não rastreados acumulam lixo: builds, caches, temporários. git clean -n mostra o que seria removido, git clean -f remove arquivos e -fd inclui diretórios. Cuidado: o comando não pede confirmação na versão forçada. Use -n sempre antes, pois não há como desfazer.

12. git remote -v e git remote prune

Verificar os remotes configurados evita pushes para o repositório errado. git remote -v lista URLs, e git remote prune origin remove referências locais de branches deletadas no remoto. Isso mantém o git branch -a limpo e evita confusão ao listar branches antigas.

13. git archive

Para exportar o código sem histórico, git archive --format=zip HEAD > projeto.zip gera um snapshot limpo. Útil para compartilhar código com quem não usa git ou para gerar pacotes de deploy. Diferente de copiar a pasta, o archive ignora arquivos do .gitignore automaticamente.

Qual comando usar primeiro?

Se você só pode adotar um comando hoje, comece pelo git rebase -i. Ele muda a forma como você apresenta seu trabalho: commits limpos, revisão mais rápida e histórico legível. Depois, adicione o git bisect ao seu fluxo de debugging. Esses dois sozinhos já reduzem o retrabalho em projetos de médio porte.

Perguntas frequentes sobre comandos git avançado

Qual a diferença entre git reset e git revert?

O reset move o ponteiro HEAD para trás, reescrevendo o histórico local. O revert cria um novo commit que desfaz as mudanças, preservando o histórico original. Use reset em branches locais e revert em branches compartilhadas ou produção.

Como recuperar um commit perdido com git reflog?

Rode git reflog para listar todos os movimentos do HEAD. Identifique o hash do commit perdido (aparece como HEAD@{n}) e execute git reset --hard <hash>. O reflog guarda entradas por cerca de 90 dias.

O que o git cherry-pick faz exatamente?

Ele copia um commit específico de uma branch para outra, aplicando as mudanças como um novo commit. Não mescla branches inteiras. É útil para hotfixes ou para aplicar uma correção que foi feita em uma linha de desenvolvimento diferente.

Quando usar git stash em vez de criar uma branch?

Use stash para mudanças temporárias que você não quer commitar ainda, como experimentos rápidos. Se a mudança vai levar mais de um dia, crie uma branch dedicada. Stash é frágil se você tem muitos arquivos não rastreados.

Git rebase interativo é seguro para iniciantes?

É seguro se você nunca enviou os commits para uma branch compartilhada. Em branches locais, você pode reescrever o histórico à vontade. O risco aparece quando outros devs já puxaram esses commits: o rebase cria hashes novos e causa conflitos desnecessários.