Git stash pop: preserve seu trabalho ao trocar de branch

Se você tem um trabalho pela metade que ainda não está pronto para dar commit, mas precisa mudar de contexto agora, não faça um commit "WIP". E não copie e cole suas alterações em um arquivo de texto como se fosse 2005. git stash é tudo o que você precisa.

Esse comando é a forma ideal de preservar alterações não commitadas enquanto você muda de contexto. Ele permite guardar mudanças temporariamente, resolver tarefas urgentes em outras branches e restaurar tudo exatamente de onde você parou.

Neste artigo, vou mostrar como o git stash pop funciona, quando usá-lo no lugar do git stash apply e como se recuperar quando os conflitos inevitavelmente aparecerem.

Se você é novo em Git e acha o conceito de stash confuso, comece dominando os fundamentos. Nossos cursos Introduction to Git e Introduction to GitHub vão te colocar no ritmo em pouco tempo.

Entendendo o Git stash

Git stash é um armazenamento temporário para alterações não commitadas.

Pense nele como uma área de transferência do seu trabalho. Você tem mudanças no diretório de trabalho que ainda não estão prontas para commit, mas precisa trocar de branch ou puxar atualizações do remoto. Em vez de perder seu trabalho ou fazer um commit WIP, você coloca no stash.

O comando salva suas modificações e reverte o diretório de trabalho para coincidir com o commit HEAD.

A ideia de usar stash no Git

O stash resolve um problema simples: o Git não deixa você trocar de branch com alterações não commitadas.

Digamos que você esteja trabalhando em uma feature quando chega um bug report. Você precisa mudar para outra branch agora, mas tem código pela metade e arquivos modificados. Um commit não faz sentido porque o trabalho está incompleto. Um checkout forçado faria você perder as mudanças.

É aí que entra o stash.

Aqui estão os cenários mais comuns em que o stash ajuda:

1. Trocar de branch para um trabalho urgente: você está no meio de uma feature quando precisa corrigir um bug em produção.
2. Puxar mudanças remotas: seu colega fez push de atualizações e você precisa dar pull, mas tem modificações locais.
3. Evitar commits bagunçados: você não está pronto para commitar, mas precisa de um diretório limpo para fazer rebase ou merge.
4. Salvar código experimental: você quer testar outra abordagem sem perder seu trabalho atual

Stash é rápido e reversível — sem precisar pensar em mensagens de commit ou nomes de branch.

A pilha (stack) do stash

O Git mantém os stashes em uma pilha LIFO (last-in, first-out).

Cada vez que você cria um stash, o Git adiciona uma nova entrada no topo da pilha. O stash mais recente vira stash@{0}, e os mais antigos descem: stash@{1}, stash@{2} e assim por diante.

Por baixo dos panos, cada stash é na verdade um commit — ou melhor, um conjunto de commits. O Git cria uma estrutura de commit com múltiplos pais que armazena:

1. Suas mudanças no diretório de trabalho
2. Suas mudanças staged (o index)
3. Arquivos não rastreados (se você usou a flag u)

Isso significa que stashes não são apenas snapshots. Eles são commits completos que o Git pode mesclar de volta no seu diretório de trabalho depois.

Você pode referenciar stashes de duas formas — por índice usando a sintaxe stash@{0}, ou executando git stash list para encontrar a mensagem que você deu e referenciar aquele stash específico. O índice é mais rápido para stashes recentes, mas as mensagens ajudam quando você tem vários stashes salvos.

Veja como uma pilha típica de stashes costuma parecer:

O prefixo WIP on significa que você usou git stash sem mensagem. O prefixo On indica que você forneceu uma mensagem personalizada com git stash push -m.

Os stashes vivem apenas no seu repositório local — eles não são enviados para o remoto. Isso mantém seu trabalho temporário onde deve estar: na sua máquina, pronto para ser restaurado quando você precisar.

Criando, gerenciando e examinando stashes

O comando básico git stash já resolve o essencial, mas é preguiçoso. Você vai acabar com uma pilha de entradas "WIP on nome-da-branch" que não dizem nada sobre o conteúdo. Seis semanas depois, você não vai lembrar qual stash tem a correção de bug e qual é o refactor pela metade.

Agora vou te mostrar como fazer do jeito certo desde o começo.

Criando stashes com boas descrições

A forma mais simples de criar um stash é digitando git stash:

git stash

Isso salva suas mudanças, mas a mensagem "WIP on main" não é nada informativa. Você não consegue saber o que tem ali sem inspecionar.

Em vez disso, rode git stash push -m com uma mensagem descritiva:

git stash push -m "Updated file.txt"

Agora sua lista de stashes fica realmente informativa:

A diferença é gritante. Uma entrada diz exatamente o que você fez, enquanto a outra te deixa adivinhando.

Escreva mensagens como se estivesse deixando recados para o seu “eu do futuro”. "Adicionar lógica de autenticação", "Corrigir bug da navbar" ou "Experimentar novo design de API" são infinitamente melhores que mensagens genéricas de WIP.

Incluindo arquivos não rastreados ou ignorados

Por padrão, git stash só salva arquivos rastreados — aqueles que o Git já conhece.

Arquivos não rastreados permanecem no seu diretório de trabalho. Isso pega muita gente de surpresa quando fazem stash, trocam de branch e ainda veem os arquivos novos por lá.

Veja o que acontece:

echo "new_feature.py" > new_feature.py
git stash

O arquivo não foi para o stash porque o Git ainda não o rastreia:

Para contornar isso, use a flag -u para incluir arquivos não rastreados no stash:

git stash push -u -m "Added a Python file for a new cool feature"

Isso coloca no stash tanto os arquivos rastreados quanto os não rastreados. Seu diretório de trabalho fica totalmente limpo.

Dica: você pode adicionar a flag -a para incluir também os arquivos ignorados. Ela coloca no stash arquivos rastreados, não rastreados e os que estão no seu .gitignore. Você raramente vai precisar disso, a não ser que esteja depurando problemas de build ou queira salvar um snapshot completamente limpo de tudo.

Aqui vai um guia rápido para saber quando usar cada flag:

1. Sem flag: você só alterou arquivos existentes

2. u (flag): você adicionou novos arquivos que ainda não são rastreados

3. a (flag): você precisa salvar tudo, incluindo outputs de build ou arquivos temporários

Na maioria das vezes, você vai usar -u. É a aposta mais segura quando você criou novos arquivos durante o desenvolvimento.

Stash parcial ou seletivo

Você não precisa colocar tudo no stash.

Suponha que você corrigiu dois bugs, mas só quer colocar um deles no stash. Ou você fez mudanças em cinco arquivos, mas apenas três estão relacionados à feature que quer salvar.

Você pode fazer stash de arquivos específicos com pathspec:

git stash push -m "New files" new_file.txt new_file_2.txt

Isso coloca no stash apenas new_file.txt e new_file_2.txt. O restante permanece no seu diretório de trabalho.

Você também pode usar curingas:

git stash push -m "Stash all txt files" *.txt

Ou usar --patch para um stash interativo:

git stash push --patch

O Git percorre cada mudança e pergunta se você quer colocá-la no stash. Você responde y (sim), n (não) ou s (split — dividir esse trecho em partes menores).

Isso é útil quando você tem mudanças relacionadas e não relacionadas no mesmo arquivo. Você coloca no stash o trabalho da feature e deixa para trás o código de debug.

Veja como é o prompt interativo:

Listando e examinando stashes

Como você já viu, dá para rodar git stash list para ver tudo o que foi colocado no stash:

O stash mais recente é sempre stash@{0}. Os mais antigos descem no índice.

Se você escreveu boas mensagens, consegue escanear a lista e saber exatamente o que tem em cada stash. Caso contrário, vai precisar inspecioná-los um por um.

Use git stash show para ver um resumo:

Isso mostra quais arquivos mudaram e quantas linhas foram adicionadas ou removidas.

Se preferir, use git stash show -p para ver o diff completo:

A flag -p mostra as mudanças de código, como no git diff. É assim que você confirma que vai dar pop no stash certo antes de rodar git stash pop.

O que o Git stash pop realmente faz

Agora vamos falar sobre o que o git stash pop faz de fato e por que usá-lo.

Comportamento e sintaxe básicos

O git stash pop faz duas coisas: aplica as mudanças do seu stash e depois remove esse stash da pilha.

A sintaxe básica é:

git stash pop

Isso dá pop no stash mais recente (stash@{0}) e o remove da sua lista.

Você também pode dar pop em um stash específico referenciando o índice:

git stash pop stash@{1}

Isso aplica o stash@{1} e o remove, mas tem um detalhe: os stashes restantes sobem um nível. O que era stash@{2} vira stash@{1}, e assim por diante.

Como o Git processa um stash pop

Quando você roda git stash pop, o Git faz um merge a três vias nos bastidores.

Ele compara três estados:

1. O commit base (onde você criou o stash)
2. Seu commit HEAD atual
3. As mudanças do stash

Se o merge acontecer sem conflitos, o Git aplica suas mudanças e remove o stash. Seu diretório de trabalho fica exatamente como estava antes do stash.

Exemplo simples de fluxo:

# You're working on a feature
echo "new feature code" >> feature.py
git stash push -m "Half-finished feature work"

# Switch to new branch and make unrelated changes
git checkout bugfix
echo "bug fix" >> bugfix.py
git add bugfix.py
git commit -m "Fix critical bug"

# Go back to your other branch
git checkout main

# Pop your stashed work
git stash pop

Se o Git não conseguir mesclar limpo, você terá um conflito. O stash permanece na pilha porque o pop não foi concluído com sucesso. Você verá marcadores de conflito nos arquivos, como em um merge comum.

Quando houver conflitos, você precisa resolvê-los manualmente, fazer stage dos arquivos corrigidos e commitar. O stash não desaparece automaticamente, então você terá que rodar git stash drop depois de resolver tudo.

Aplicando stashes entre branches

Stashes não ficam presos a uma branch específica.

Você pode criar um stash na bugfix, mudar para a main e dar pop nele lá. O Git não se importa de onde veio — ele só tenta aplicar as mudanças na branch em que você está.

Isso abre algumas possibilidades úteis:

1. Mover trabalho entre branches: você começou a codar na branch errada. Em vez de resetar e perder trabalho, faça stash, troque para a branch certa e dê pop lá.

2. Reorganizar tarefas: você colocou um código experimental no stash há uma semana. Agora quer testá-lo em outra branch para ver se funciona melhor lá.

3. Testar mudanças em contextos diferentes: você tem uma correção de bug no stash e quer testá-la em várias branches antes de commitar. Use git stash apply em vez de pop para manter o stash, testar em branches diferentes e só dar pop na branch onde vai commitar. Falo mais sobre apply já já.

Enquanto não houver conflito com a branch atual, o stash aplica limpo — é isso que você precisa ter em mente.

Git stash pop vs git stash apply

Muita gente fica na dúvida entre usar git stash pop ou git stash apply.

A principal diferença: persistência do stash

A diferença é simples: pop remove o stash depois de aplicar, enquanto apply mantém o stash na pilha.

Com o pop, você está dizendo: “terminei com esse stash — aplique e jogue fora”. Com o apply, você diz: “posso precisar disso de novo depois”.

Isso impacta seu fluxo de duas maneiras:

1. Segurança: se algo dá errado durante um pop e você precisa se recuperar, o stash já foi embora. Com o apply, o stash permanece como backup.

2. Limpeza: usar pop mantém sua lista de stashes limpa automaticamente. Usando apply, você precisa rodar git stash drop depois para remover os stashes que já não precisa.

A maioria dos desenvolvedores usa pop por ser mais limpo. Mas apply é melhor quando você não tem certeza se o stash vai aplicar limpo na branch atual, ou quando quer testar as mesmas mudanças em várias branches.

Previsibilidade, risco e mudança de índices

Aqui está onde o pop complica — os índices mudam quando você dá pop no meio da pilha.

Suponha que você tenha três stashes:

stash@{0}: Feature work
stash@{1}: Bug fix
stash@{2}: Experimental code

Se você der pop no stash@{1}, os stashes restantes sobem:

stash@{0}: Feature work
stash@{1}: Experimental code

Isso pode causar problemas se você estiver automatizando operações do Git ou rodando vários pops em sequência. Você dá pop no stash@{1}, depois tenta dar pop no stash@{2}, mas esse índice já não existe.

O comando apply não sofre com isso. Os índices só mudam quando você executa explicitamente git stash drop. Você pode aplicar stashes em qualquer ordem sem se preocupar com a pilha mudando por baixo de você.

Tratamento de conflitos idêntico

Ambos os comandos tratam conflitos da mesma forma.

Se o Git não conseguir mesclar seu stash limpo, você verá marcadores de conflito nos arquivos. A diferença é o que acontece com o stash:

1. Com pop: o stash fica na pilha porque o pop não concluiu com sucesso

2. Com apply: o stash permanece na pilha (como já ficaria de qualquer forma)

Nos dois casos, você precisa corrigir os conflitos manualmente, fazer stage com git add dos arquivos resolvidos e remover o stash com git stash drop (se usou apply).

O fluxo de resolução é idêntico — a única diferença é se o stash seria removido automaticamente em caso de sucesso.

Quando escolher cada um

Use git stash pop quando:

1. Você vai aplicar o stash uma vez e encerrar com ele
2. Quer manter sua lista de stashes limpa automaticamente
3. Está trabalhando em uma única branch e não precisa do stash em outro lugar

Use git stash apply quando:

1. Quer testar as mesmas mudanças em várias branches
2. Não tem certeza se o stash vai aplicar limpo
3. Está automatizando operações do Git e precisa de índices previsíveis
4. Quer uma rede de segurança caso algo dê errado

Lidando com conflitos no stash pop

Conflitos acontecem quando o Git não consegue mesclar seu stash de forma limpa. Nesta seção, vou te mostrar como lidar com eles.

Quando e por que os conflitos ocorrem

O conflito acontece durante o merge a três vias que o Git faz ao dar pop no stash.

O Git compara três versões do seu código:

1. O commit base onde você criou o stash
2. Seu commit HEAD atual
3. As mudanças do stash

Se as mesmas linhas mudaram tanto na branch atual quanto no stash, o Git não sabe qual versão manter. Isso é um conflito.

Causas comuns de conflitos ao dar pop no stash:

1. Você modificou o mesmo arquivo nas duas branches: você colocou mudanças no stash, trocou de branch e editou o mesmo arquivo antes do pop
2. Alguém fez push de mudanças: você fez stash, deu pull do remoto e essas atualizações mexeram no mesmo trecho de código
3. Você fez rebase ou cherry-pick: o commit base esperado pelo Git não existe mais, causando divergências no merge

Em geral, quanto mais tempo um stash fica parado, maior a chance de você encarar conflitos quando finalmente der pop.

Fluxo para resolver conflitos

Quando ocorre um conflito, o Git pausa o pop e marca os conflitos nos arquivos:

Seu arquivo agora contém marcadores de conflito:

Tudo entre <<<<<<< Updated upstream e ======= é seu código atual. Tudo entre ======= e >>>>>>> Stashed changes vem do stash.

Veja como corrigir:

1. Abra o arquivo com conflito e decida qual versão manter (ou combine as duas)

2. Remova os marcadores de conflito (<<<<<<<, =======, >>>>>>>)

3. Faça stage do arquivo resolvido com git add

4. Remova o stash manualmente com git stash drop — lembre que ele não some automaticamente.

Estratégias alternativas

Se você não quer lidar com conflitos na branch atual, use git stash branch.

Esse comando cria uma nova branch a partir do commit onde o stash foi feito e aplica o stash nela:

git stash branch temp-feature

O Git cria uma branch chamada temp-feature, faz checkout e dá pop no seu stash nela. Como a branch começa exatamente no commit onde você criou o stash, não haverá conflitos. Vou detalhar isso melhor em uma seção separada.

Você também pode abortar um pop que falhou com git reset --merge:

git stash pop

# Conflicts appear

git reset --merge

Isso desfaz a tentativa de pop e reverte seu diretório de trabalho ao estado anterior. O stash permanece na pilha.

Abortando operações de stash em andamento

Se você começou um pop ou apply e quer desistir totalmente, há opções.

Para conflitos que você ainda não começou a resolver, rode:

git reset --merge

Isso cancela o merge e limpa seu diretório de trabalho. Tudo volta ao que era antes do comando de stash.

Para conflitos que você já começou a resolver, rode:

git reset --hard HEAD

Esse comando descarta todas as mudanças no diretório de trabalho, incluindo correções que você já fez. Use quando tudo ficou confuso e você quer recomeçar do zero.

Lembre-se: esse comando destrói trabalho não commitado. Tenha certeza de que quer realmente descartar tudo antes de executá-lo.

Depois de abortar, seu stash continua na pilha (a menos que você tenha usado pop e ele tenha sido bem-sucedido antes dos conflitos). Você pode tentar novamente mais tarde ou usar git stash branch para uma abordagem mais limpa.

Limpando os stashes

Stashes acumulam rápido em projetos de longa duração. Você faz stash para corrigir um bug e depois esquece. Cria stashes experimentais que nunca são aplicados. Seis meses depois, tem 20 stashes e não faz ideia do conteúdo da metade deles.

Isso dificulta encontrar o stash que você realmente precisa. Você acaba rodando git stash show -p em cada um só para descobrir o que tem dentro.

É uma baita perda de tempo, então lembre de limpar seus stashes com frequência.

Removendo stashes individuais

Use git stash drop para remover um stash específico:

git stash drop stash@{2}

Isso apaga o stash@{2} da pilha. Os restantes sobem — o que era stash@{3} vira stash@{2}.

Você também pode remover o stash mais recente sem especificar o índice:

git stash drop

Isso remove o stash@{0} por padrão.

Pela minha experiência com Git, os principais motivos para descartar stashes são:

1. Você percebe que não precisa mais das mudanças
2. Você tem stashes duplicados (acontece mais do que parece)
3. O stash é tão antigo que você nem lembra para que servia

Se estiver na dúvida, use git stash show -p para inspecionar antes de descartar. Melhor prevenir do que remediar.

Limpando a pilha inteira

Você pode usar git stash clear para apagar todos os stashes de uma vez:

git stash clear

Lembre que isso é permanente. Não dá para desfazer ou recuperar os stashes depois.

Só use git stash clear quando tiver absoluta certeza de que não precisa de nenhum stash.

Na maioria dos casos, é melhor descartar individualmente para não apagar algo útil por engano.

Criando branches a partir de stashes

Às vezes, a solução mais limpa é transformar um stash em uma branch. Isso evita conflitos de merge e dá um lar adequado ao seu trabalho.

Usando git stash branch

O comando git stash branch cria uma nova branch e aplica seu stash nela:

O que acontece:

1. O Git cria uma nova branch chamada feature-experiment a partir do commit onde você fez o stash

2. O Git faz checkout dessa branch

3. O Git dá pop no stash nessa branch

4. O Git remove o stash da sua pilha (como o pop)

Como a branch começa no mesmo commit do stash, não haverá conflitos. As mudanças aplicam limpas sempre.

Você também pode usar um stash específico em vez do mais recente:

git stash branch new-feature stash@{2}

Casos de uso comuns

Criar uma branch a partir de um stash é perfeito para features experimentais. Digamos que você guardou um código experimental no stash há uma semana e agora quer desenvolvê-lo direito sem bagunçar seu trabalho atual.

Você ganha uma branch limpa para trabalhar no experimento. Se der certo, faz merge. Se não, apaga a branch e segue o jogo.

Também é ótimo para rebases longos. Em vez de lidar com possíveis conflitos durante o rebase, você pode colocar tudo no stash e criar uma branch a partir dele.

git stash push -m "WIP before rebase"
git rebase main
git stash branch temp-work

Agora você pode revisar as mudanças do stash separadamente e decidir como integrá-las depois do rebase.

Criar uma branch também ajuda a isolar mudanças grandes ou bagunçadas. Imagine um stash enorme com alterações em 15 arquivos, metade em conflito com a branch atual. Crie uma nova branch — não precisa travar uma batalha.

Você terá uma branch dedicada para revisar tudo com calma, commitar direitinho e depois fazer merge com um histórico claro.

Técnicas avançadas e opções de recuperação

Agora que você já domina o básico do git stash, vamos ver alguns conceitos mais avançados.

Trabalhando com entradas específicas do stash

Você pode dar pop ou aplicar qualquer stash da pilha, não só o mais recente.

Basta referenciá-los pelo índice para pegar exatamente o que precisa:

git stash pop stash@{3}
git stash apply stash@{1}

Isso permite pegar stashes antigos sem mexer nos mais novos. Ao dar pop em um stash intermediário, todos os índices abaixo sobem. O que era stash@{4} vira stash@{3}, e assim por diante. Se você estiver automatizando operações ou dando pop em sequência, essa mudança de índice pode quebrar seus comandos.

A solução é usar apply em vez de pop quando precisar de índices previsíveis:

git stash apply stash@{2}

# Drop it manually when you're done
git stash drop stash@{2}

Assim você controla exatamente quando a pilha muda. Aplique o stash, verifique se funcionou e só então remova. Os índices só mudam quando você manda.

Restaurando o estado staged

Por padrão, git stash pop e git stash apply restauram suas mudanças, mas não preservam o que estava staged.

Digamos que você tinha três arquivos modificados e dois deles já estavam staged antes do stash. Quando você der pop, os três voltam como mudanças não staged. O Git perde a noção do que você queria commitar.

A solução é usar a flag --index para restaurar o staging exatamente como estava:

git stash pop --index

Isso recria seu working tree e index exatamente como antes do stash. Arquivos que estavam staged continuam staged. Os que não estavam, continuam não staged. Tudo volta ao lugar.

Você vai precisar dessa flag quando:

1. Estiver preparando um commit cuidadosamente staged e não puder perder essa informação

2. Estiver trabalhando com cenários complexos de staging, como quando usou git add -p para selecionar apenas partes de arquivos

3. Quiser que seu diretório de trabalho fique idêntico ao que era antes do stash, sem exceções

Na maioria das vezes, você não vai precisar dessa flag. Você dá pop, vê o que voltou e faz stage do que for necessário.

Recuperando-se de erros com stash

Em algum momento você vai descartar um stash que precisava ou limpar a pilha inteira sem querer.

Se isso acontecer, o reflog do Git pode salvar seu dia.

O reflog registra toda mudança de referência no repositório, incluindo stashes. Quando você cria ou remove um stash, o Git registra no reflog. Mesmo após remover, os commits ainda existem por um tempo como objetos inalcançáveis.

Você pode encontrar o stash perdido procurando commits inalcançáveis:

git fsck --unreachable | grep commit

Agora verifique cada commit para encontrar seu stash:

git show 066ded985342e585bc8e75c074add99ec1950f50

Veja o diff e a mensagem do commit para identificar qual é o seu stash perdido. Quando encontrar, recupere-o:

git stash apply 066ded985342e585bc8e75c074add99ec1950f50

Isso aplica o stash perdido no seu diretório de trabalho como se ele nunca tivesse sido removido.

Melhor ainda, evite erros seguindo estas boas práticas:

1. Escreva mensagens descritivas para cada stash, assim você sabe exatamente o que está removendo. "Corrigir bug de login" é bem melhor do que "WIP" quando há cinco stashes na lista.

2. Use git stash show -p antes de remover para confirmar que é o stash certo. Gaste cinco segundos verificando em vez de cinco minutos recuperando.

3. Limpe sua pilha de stashes regularmente para não virar bagunça. Uma pilha com três stashes relevantes é muito mais fácil de navegar do que uma com 15 entradas antigas.

4. Use apply em vez de pop quando não tiver 100% de certeza de que quer deletar o stash. Você pode removê-lo depois que tudo estiver verificado.

A recuperação via reflog funciona, mas é trabalhosa. Basta olhar a imagem acima para ver quantos commits eu teria que checar manualmente — e este é um projeto pequeno criado só para este artigo.

Boas práticas e diretrizes de fluxo

Usar stashes bem significa seguir padrões que evitam erros e mantêm seu fluxo de trabalho limpo. Aqui vai a abordagem que eu recomendo.

Padrões de fluxo recomendados

O fluxo mais seguro segue um padrão simples: faça stash com mensagem, mude de contexto e dê pop quando estiver pronto para continuar.

# Work on feature-branch
git stash push -m "Feature work in progress"

git checkout main
# Do urgent work on main

# Go back
git checkout feature-branch
git stash pop

Isso resolve a maioria dos casos. Você preserva o trabalho, lida com a interrupção e restaura tudo sem stress.

Outro padrão comum é o “inspecione antes do pop”. Você lista os stashes, examina o conteúdo e depois dá pop no correto.

git stash list
git stash show -p stash@{1}
git stash pop stash@{1}

Essa verificação extra evita aplicar o stash errado ou trazer trabalho desatualizado.

Alguns desenvolvedores preferem o “commit relutante” em vez do stash. Ao invés de usar stash, fazem um commit temporário com mensagem tipo "WIP - not ready" e depois ajustam (amend) ou resetam. Funciona se você não curte stash ou quer o trabalho registrado no histórico da branch. A desvantagem é acabar com logs de commit bagunçados se esquecer de limpar depois.

Integração com ferramentas de desenvolvimento

A maioria das GUIs de Git mostra seus stashes visualmente e permite aplicar ou dar pop com um clique.

Ferramentas como GitKraken, Sourcetree e GitHub Desktop listam seus stashes em uma barra lateral. Você vê a mensagem, inspeciona o diff e aplica ou remove sem digitar comandos. É útil quando você tem vários stashes e quer compará-los lado a lado.

A extensão de Git do VS Code mostra stashes no painel de controle de código-fonte. Você pode clicar com o botão direito para dar pop, aplicar ou remover sem sair do editor.

Aliases no shell deixam tudo mais rápido para quem prefere a linha de comando. Adicione ao seu .bashrc ou .zshrc:

alias gst='git stash'
alias gstp='git stash pop'
alias gstl='git stash list'
alias gsts='git stash show -p'

Agora gst faz o stash, gstp dá pop, gstl lista os stashes e gsts mostra o diff. Você economiza alguns toques toda vez.

Higiene do stash e trabalho em equipe

Stashes são locais — nunca são enviados para repositórios remotos.

Isso significa que seus colegas não veem seus stashes e você não acessa os seus em outro computador. Se precisar compartilhar trabalho em andamento, não use stash. Prefira patches ou branches temporárias.

Para compartilhar via patches, rode:

git stash show -p > my-work.patch
# Send the patch file to your teammate
# They apply it with: git apply my-work.patch

Agora envie o arquivo de patch ao colega, e ele vai aplicar executando git apply my-work.patch.

Para compartilhar via branches temporárias, rode:

git checkout -b temp/work-in-progress
git add .
git commit -m "WIP - authentication feature"
git push origin temp/work-in-progress

Seu colega pode puxar a branch, revisar o trabalho e continuar a partir dali.

Seja qual for sua abordagem, mantenha uma boa higiene de stash. Isso evita confusão e mantém a pilha gerenciável. Boas práticas:

1. Use descrições claras em todo stash. "Adicionar lógica de autenticação" diz o que tem. "WIP na feature-branch" não diz nada.

2. Limpe os stashes semanalmente. Rode git stash list e remova o que for mais antigo que uma semana. Se você não precisou em sete dias, provavelmente não vai precisar.

3. Não deixe a contagem passar de cinco. Mais que isso indica uso como armazenamento de longo prazo, não algo temporário. Dê pop, commite o trabalho ou remova.

4. Se estiver em equipe e alguém perguntar “cadê aquele código em que você estava?”, nunca responda “está no meu stash”. Stashes são privados e temporários — não servem para compartilhar ou arquivar algo importante.

Conclusão

Agora você sabe como o git stash pop funciona e quando usá-lo.

No essencial, stashing é simples: salve seu trabalho não commitado, mude de contexto e restaure depois. Mas os detalhes importam. Saber quando usar pop ou apply, como lidar com conflitos e quando criar branches a partir de stashes vai te poupar horas de frustração.

O ponto mais importante: stashes são armazenamento temporário, não backup permanente. Escreva descrições úteis, limpe com regularidade e não deixe a pilha passar de cinco entradas. Se precisar compartilhar ou manter por mais tempo, commite em uma branch.

Se você curtiu este artigo e quer evoluir no Git, seus próximos passos são nossos cursos Intermediate Git e Intermediate GitHub Concepts.