Introdução
O Local History é um daqueles recursos da IDE que você não pensa — até precisar desesperadamente. Este post cobre o que é, como funciona e os cenários onde ele salva você: rollbacks acidentais, alterações não commitadas perdidas e erros em rebase.
Era uma sexta-feira à tarde. Eu estava trabalhando em uma feature há dias, tinha feito um progresso sólido e estava prestes a commitar. Me confundi com qual branch eu estava trabalhando e, em vez disso, cliquei em “Discard Changes” no VSCode… poof. Todas as alterações revertidas. O projeto parecia que eu não tinha tocado nele há uma semana.
Eu não tinha commitado ainda. git status não mostrava nada. As alterações nunca foram para stage. Dias de trabalho, desaparecidas.
Depois de um Google desesperado, tropecei em algo que nunca tinha usado em IDEs JetBrains: Local History. E lá estava — cada salvamento que eu tinha feito, cada alteração, ordenadamente listada. Peguei a versão de segundos antes do meu rollback desastroso, cliquei em “Revert”, e meu código voltou.
Naquele dia, o Local History passou de “algum item de menu que eu sempre ignorava” para “o recurso mais importante que eu nunca soube que tinha.”
O que é o Local History?
Local History é um recurso embutido em todas as IDEs JetBrains (Rider, IntelliJ IDEA, WebStorm, etc.) que monitora automaticamente alterações nos seus arquivos enquanto você trabalha. Cada vez que você salva, a IDE armazena um snapshot do arquivo. Ela mantém uma linha do tempo de todos esses snapshots, permitindo que você:
- Veja o diff entre quaisquer duas versões
- Reverta um arquivo para qualquer estado anterior
- Compare o código atual com um ponto específico no tempo
- Adicione rótulos a snapshots importantes para referência futura
A diferença chave do versionamento (git): Local History é automático e local. Não depende de você lembrar de commitar, dar stage ou sequer salvar intencionalmente (embora dispare em eventos de salvamento). Está sempre rodando em segundo plano, mantendo uma rede de segurança dos últimos dias de trabalho (configurável).
O Local History Rastreia Alterações Externas?
Sim. Se um arquivo for modificado fora da IDE (comandos git via terminal ou em outro editor), a IDE detecta a mudança e cria uma entrada no Local History com o rótulo “External change” mostrando o diff completo.
Por padrão, a detecção acontece quando:
- A janela da IDE ganha foco — voltar ao Rider/IntelliJ dispara uma sincronização de arquivos (controlado pela configuração “Synchronize files on frame activation”, ativada por padrão)
- Você interage com o arquivo — clicar na aba ou tentar editar dispara uma verificação
Se a IDE está rodando mas minimizada ou em segundo plano, alterações externas podem não ser detectadas imediatamente — elas sincronizam quando você volta (alt-tab) para a janela. Se a IDE estava completamente fechada, o último snapshot é de antes do fechamento; o próximo é tirado quando reabre e detecta o arquivo modificado. Esse estado intermediário é perdido.
Recomendado: Ative a Sincronização Periódica
Você pode contornar a necessidade de foco. Vá em File → Settings → Appearance & Behavior → System Settings → Sync external changes e altere para “Periodically when the IDE is inactive (experimental)”. Isso recarrega arquivos alterados externamente a cada ~15 segundos quando a IDE está ociosa — sem precisar trocar de janela.
Quando o Git Não Consegue Ajudar
Git é incrível, mas tem pontos cegos. Aqui estão os cenários onde o Local History brilha:
1. O Rollback Acidental (Minha História)
Você seleciona um arquivo e descarta as alterações, esperando desfazer uma alteração específica. Mas ele reverte o arquivo inteiro para o último estado commitado. Se você tinha alterações não commitadas em vários métodos, acabou de perder todas elas.
git reflog não vai ajudar porque nada foi para stage ou commitado. git restore não pode restaurar o que nunca foi salvo no banco de objetos do git. Local History é a única saída.
2. Perdido Durante um Rebase
Rebase é poderoso mas perigoso, porque você pode resolver um conflito errado e não perceber até mais tarde.
Durante um rebase, o git pausa em um conflito. Você abre o arquivo e resolve os conflitos. Mas em um merge complexo, é fácil escolher acidentalmente o lado errado, deletar algo que deveria ficar, ou perder um hunk inteiro. O git aceita sua resolução e segue em frente. Sem aviso. O código errado agora faz parte do histórico rebaseado.
Depois de perder alterações em um rebase, eu agora sempre crio uma branch de backup ou uma tag antes de iniciar um rebase. Ou até faço esta abordagem que evita múltiplas resoluções de conflito em primeiro lugar.
3. Arquivos Novos Não Rastreados Perdidos na Troca de Branch
Você cria um arquivo novo na branch A; nunca enviado para stage, nunca commitado. Git trata como untracked, então quando você troca para a branch B, o arquivo vem junto silenciosamente (git não limpa arquivos untracked).
Na branch B, você esquece que o arquivo era da outra branch. Edita, deleta ou sobrescreve achando que faz parte do trabalho da B. Quando volta para a A, o arquivo sumiu.
O Local History monitora arquivos novos desde o momento que você cria e salva. Abra o Local History no diretório, encontre o snapshot com seu arquivo e recupere o conteúdo.
Como Acessar o Local History
Acessar o Local History no Rider é direto:
Mostrar Histórico de um Arquivo
Clique com o botão direito em um arquivo no editor ou Solution Explorer → Local History → Show History.
Isso abre um diálogo com:
- Painel esquerdo: Uma linha do tempo das versões salvas (com timestamps)
- Painel direito: Uma visão diff comparando a versão selecionada com o arquivo atual
- Ações: Reverter, Criar Patch, Comparar com… (e um botão de restaurar na barra de ferramentas)
Mostrar Histórico de um Diretório
Você também pode clicar com o botão direito em um diretório → Local History → Show History. Isso mostra alterações em todos os arquivos do diretório — útil para entender o que mudou em vários arquivos em uma sessão.
Ações Principais no Diálogo de Histórico
| Ação | Descrição |
|---|---|
| Revert | Restaura o arquivo para a versão histórica selecionada |
| Create Patch | Gera um arquivo .patch das diferenças entre duas versões |
| Compare | Visualiza um diff lado a lado de duas versões históricas |
| Label | Adiciona um nome significativo a um snapshot (ex.: “Antes da refatoração da IA”) |
Configuração
Você pode configurar a retenção do Local History em File → Settings → Advanced Settings → IDE section → Duration of storing changes in Local History. O padrão é 5 dias úteis (dias em que o arquivo foi modificado), mas você pode aumentar.
O Local History também tem um tamanho máximo de armazenamento, então revisões antigas não têm garantia de persistir indefinidamente.
⚠️ Os dados do Local History são armazenados em disco no diretório de cache da IDE. Não são copiados para a nuvem nem compartilhados com seu time. Se você limpar os caches da IDE ou trocar de máquina, o Local History é perdido.
Conclusão
Local History é um daqueles recursos de IDE que parece comum — até ele salvar o seu dia. Ele preenche a lacuna entre seus commits no git, capturando salvamentos ao longo do caminho.