# 13 comandos git avançado que todo dev deveria dominar

> O Git oferece 13 comandos avançados para desenvolvedores que buscam otimizar o fluxo de trabalho e reduzir retrabalho. Comandos como `git reflog`, `git cherry-pick` e `git bisect` permitem recuperar commits perdidos, aplicar mudanças específicas e identificar regressões com precisão. O domínio dessas ferramentas eleva a eficiência em code reviews e na resolução de conflitos, posicionando o profissional como sênior no controle de versão.

*Net Propaganda · Apps e Software · 28 de agosto de 2026 · Walquíria Bensaúde Tomaz*

Você já domina o básico do git, mas sente que falta algo? Estes 13 comandos avançados vão destravar seu fluxo de trabalho, evitar retrabalho e fazer você parecer um sênior no code review.

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 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 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 . 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.

---

Fonte (canonical): https://netpropaganda.com.br/apps-e-software/13-comandos-git-avancado-que-todo-dev-deveria-dominar/
