5 comandos do Git para o dia a dia

Introdução

Bora ser honestos: você já domina o básico. git add, git commit, git push, git pull. Esses são os comandos que usamos em 80% do nosso dia a dia. Mas o que acontece quando você precisa de algo a mais? É aí que você percebe que precisa de ferramentas mais especializadas.

Aquele momento de pânico quando um git reset --hard acidental apaga horas de trabalho, ou quando um bug aparece do nada e ninguém sabe de onde veio. Esses são os momentos em que as ferramentas básicas não são suficientes.

Este artigo é o seu guia para 5 heróis desconhecidos do Git. São comandos que talvez você não use todos os dias, mas que, no momento certo, funcionam como salva-vidas.

Dica

🔥 VAI ACABAR!_

A Rocketseat está em Black Friday, trazendo as melhores condições do ano para você se tornar um profissional sensacional e concorrer a um Macbook M4 💻️

Assinatura Anual (12 meses): Garanta 30% de desconto! São mais de R$ 800 OFF para ter acesso ilimitado a todo o conteúdo por um ano inteiro.

Assinatura de Longo Prazo (5 anos): O maior desconto da história! São 67% OFF, uma economia de mais de R$ 7.500! Desconto de Black Month!

1. git stash

Cenário do dia a dia: Você está no meio de uma refatoração complexa. Vários arquivos estão modificados, nada está pronto para um commit, e seu diretório de trabalho ta uma zona. De repente tu recebe uma notificação: um bug crítico em produção precisa da sua atenção agora. Você precisa trocar de branch imediatamente, mas seu trabalho atual está em um estado caótico e inacabado.

A solução com git stash: O comando git stash é sua válvula de escape. Ele pega o estado "sujo" do seu diretório de trabalho, tanto os arquivos modificados quanto as alterações na staging area, e os salva em uma pilha temporária, limpando seu diretório para que você possa trocar de branch sem medo. O comando git stash push é a forma moderna e mais flexível, preferível em relação a alternativas mais antigas e um sinônimo mais poderoso para o git stash básico.

Exemplo Prático: Imagine que seu git status se pareça com isto: um arquivo já em stage e outro modificado, mas ainda não preparado.

$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
 
	modified:   index.html
 
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
 
	modified:   lib/simplegit.rb

Agora, execute o comando mágico:

$ git stash push
Saved working directory and index state "WIP on master: 049d078 Create index file"
HEAD is now at 049d078 Create index file

Verifique o status novamente. Tudo limpo.

$ git status
# On branch master
nothing to commit, working directory clean

Agora você pode trocar de branch, corrigir o bug e, quando voltar, ver seus stashes guardados com git stash list. Para trazer seu trabalho de volta, use git stash apply ou git stash pop. A diferença é que apply mantém o stash na lista para ser usado novamente, enquanto pop o aplica e o remove da lista em um único passo.

$ git stash list
stash@{0}: WIP on master: 049d078 Create index file
 
$ git stash apply

2. git rebase -i

Cenário do dia a dia: Seu histórico de commits antes de abrir um Pull Request parece uma conversa de WhatsApp: "arrumando bug", "agora vai", "ops, esqueci um arquivo". Um histórico limpo, com commits atômicos e mensagens claras, não é apenas estética; é crucial para a revisão de código e a manutenção futura do projeto.

A solução com rebase -i: O rebase interativo (git rebase -i) é uma ferramenta para reescrever seu histórico de commits locais. Ele permite reordenar, reescrever mensagens, juntar (squash) ou até mesmo dividir commits, transformando o caos em uma narrativa coesa e lógica.

Exemplo Prático: Para limpar seus últimos 3 commits, execute:

$ git rebase -i HEAD~3

O Git abrirá seu editor de texto com algo assim:

pick f7f3f6d Change my name a bit
pick 310154e Update README formatting and add blame
pick a5f4a0d Add cat-file
 
# Rebase 710f0f8..a5f4a0d onto 710f0f8
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# ...

Para juntar os três commits em um só, mude pick para squash (ou s) nos dois últimos:

pick f7f3f6d Change my name a bit
squash 310154e Update README formatting and add blame
squash a5f4a0d Add cat-file

Após salvar e fechar, o Git abrirá um novo editor, permitindo que você combine as três mensagens de commit em uma única mensagem clara e definitiva.

Em outras palavras, NUNCA use rebase em commits que já foram enviados para um repositório compartilhado (push). Isso reescreve a história, criando commits novos e diferentes. Isso força seus colaboradores a lidar com um histórico divergente, levando a re-merges mais complexos e a um log de commits bagunçado e duplicado quando eles tentam baixar sua "nova" história.

3. git cherry-pick

Cenário do dia a dia: Um bug foi corrigido na branch develop. A correção é perfeita e urgente, e você precisa aplicá-la agora na branch hotfix que vai para produção. O problema? A branch develop está cheia de outras features inacabadas que não podem ir para produção. Você precisa apenas daquele commit específico, nada mais.

A Solução com git cherry-pick: O git cherry-pick faz exatamente isso. Ele "pega" um commit de qualquer branch e o aplica na sua branch atual, criando um novo commit com as mesmas alterações.

Exemplo Prático: Imagine que, em um projeto Javascript, o commit com o hash e43a6 na branch develop corrigiu uma função crítica calculateTotal() no arquivo utils.js. Para aplicar apenas essa correção na sua branch hotfix, faça o checkout dela e execute:

$ git cherry-pick e43a6
Finished one cherry-pick.
[hotfix]: created a0a41a9: "fix(utils): correct calculation in calculateTotal()"
 1 file changed, 3 insertions(+), 1 deletion(-)

Um novo commit, contendo apenas aquela correção, foi criado na sua branch hotfix, pronto para ser implantado.

4. git reflog

Cenário do dia a dia: O puro terror. Você digitou git reset --hard HEAD~3 por engano, jogando fora três commits que você precisava. Ou pior, você deletou uma branch local (git branch -D minha-feature) antes de perceber que ela ainda não tinha sido enviada para o servidor. A sensação é de que todo o seu trabalho foi perdido para sempre.

A solução com git reflog: Respire fundo. O git reflog é sua rede de segurança definitiva. O Git mantém um log de referência de onde sua HEAD e suas branches estiveram nos últimos meses. Isso significa que, mesmo que um commit não esteja mais acessível por nenhuma branch, ele provavelmente ainda existe no seu reflog, esperando para ser resgatado.

Exemplo Prático: Execute git reflog e você verá uma lista de todas as suas movimentações:

$ git reflog
734713b HEAD@{0}: commit: Fix refs handling, add gc auto, update tests
d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy.
1c002dd HEAD@{2}: commit: Add some blame and merge stuff
# ...

A estrutura é id_do_commit HEAD@{índice}: ação. Imagine que você perdeu o commit 1c002dd após um reset desastroso. No seu reflog, ele está ali, seguro, como HEAD@{2}. Para restaurar esse trabalho, você pode simplesmente criar uma nova branch a partir daquele ponto:

$ git branch recovery-branch HEAD@{2}

Seu trabalho está salvo.

5. git bisect

Cenário do dia a dia: Um bug foi reportado. Você sabe que na semana passada, na tag v1.0, tudo funcionava perfeitamente. Agora, dezenas de commits depois, está quebrado. A perspectiva de testar cada commit manualmente para encontrar o culpado é, no mínimo, desanimadora.

A solução com git bisect: O git bisect é seu detetive particular. Ele automatiza a busca pelo commit problemático usando uma pesquisa binária. Você informa um commit "ruim" (onde o bug está presente) e um "bom" (onde não estava). O Git então faz o checkout de um commit no meio do caminho e pergunta: "E agora, está bom ou ruim?". Com base na sua resposta, ele divide o intervalo de busca pela metade e repete o processo até isolar o commit exato que introduziu o bug.

Exemplo Prático: Comece o processo de investigação:

$ git bisect start

Marque o commit atual como "ruim":

$ git bisect bad

Marque o último commit funcional conhecido como "bom":

$ git bisect good v1.0
Bisecting: 6 revisions left to test after this...

Agora começa o processo interativo. O Git fará o checkout de um commit. Você testa seu código.

• Se o bug desapareceu, digite: git bisect good
• Se o bug ainda está lá, digite: git bisect bad

O Git repetirá isso algumas vezes, e em questão de minutos (em vez de horas), ele apontará o culpado:

b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is the first bad commit
...

Para encerrar o processo e voltar para a sua branch original, basta executar:

$ git bisect reset

Conclusão

git add, commit e push são apenas o começo da jornada. Dominar ferramentas como stash, rebase -i, cherry-pick, reflog e bisect é o que vai te ajudar nesses momentos mais críticos. Eles oferecem uma camada extra de controle e segurança, permitindo que você manipule o histórico, recupere-se de desastres e encontre bugs com uma eficiência que parece mágica.

E você? Qual comando Git menos conhecido já salvou o seu dia? Compartilhe sua história nos comentários!