Como usar Git para recuperar uma versão do teu projeto
Para recuperar uma versão com Git, começa por identificar o que queres repor e onde essa versão está guardada. Preserva o trabalho atual, consulta o histórico e escolhe uma operação limitada ao problema. Depois, verifica o resultado antes de o publicar. Recuperar ficheiros não recupera automaticamente os dados de uma aplicação.
Define o que significa recuperar neste caso
Recuperar pode significar consultar um texto antigo, repor um ficheiro, desfazer uma alteração ou reconstruir uma aplicação. Estas tarefas têm alcances diferentes. Antes de executar comandos, descreve o resultado pretendido e o que deve permanecer. Essa definição evita repor uma versão inteira quando precisas apenas de corrigir uma pequena parte do projeto.
Imagina que a IA alterou a mensagem de confirmação de um formulário e o novo texto ficou errado. Entretanto, fizeste melhorias no menu e corrigiste uma ligação. Se o objetivo é recuperar a mensagem, voltar todo o projeto a uma versão anterior pode retirar essas melhorias sem necessidade.
Escreve uma instrução concreta: “Quero repor o conteúdo anterior do ficheiro de confirmação, mantendo as restantes alterações.” Depois, identifica o ficheiro e a versão de referência. Se ainda não sabes onde está o problema, começa por comparar as alterações, seguindo o guia para rever código sugerido pela IA.
Também convém distinguir recuperação de publicação. Podes obter o ficheiro certo no computador e ainda não ter feito qualquer alteração no site público. Essa separação permite inspecionar a correção, testar o comportamento e decidir quando a nova versão está pronta para chegar aos utilizadores.
Confirma o estado atual antes de substituir ficheiros
Antes de recuperar conteúdo, verifica a pasta em que estás e as alterações que ainda não foram registadas. O trabalho atual pode incluir correções úteis ou ficheiros novos. Guarda o que precisas de preservar através do processo apropriado ao projeto. Uma operação de recuperação deve começar com esse estado compreendido, sem depender da memória da conversa.
O comando git status mostra o estado dos ficheiros relativamente ao histórico e à preparação do próximo commit. Lê a lista e identifica alterações tuas, alterações produzidas pelo agente e ficheiros que o Git ainda não acompanha. Se existirem dúvidas sobre a origem de alguma mudança, esclarece-as antes de a substituir.
Usa git diff para observar alterações ainda não preparadas para commit e git diff --cached para as que já estão preparadas. Estas duas vistas ajudam a evitar a conclusão de que “não há diferenças” quando apenas consultaste uma parte do estado. Ficheiros novos também precisam de inspeção própria.
Se conservares trabalho num commit, revê os ficheiros incluídos e exclui segredos e dados privados. Se fizeres uma cópia separada, confirma que contém o material necessário. O método de preservação pode variar; o critério é conseguires recuperar também aquilo que estás prestes a alterar.
Procura uma versão conhecida no histórico
Escolhe a versão de referência através do histórico e do conteúdo, em vez de assumir que o commit imediatamente anterior é o correto. Uma alteração pode ter sido introduzida há vários passos. Consulta as mensagens e confirma o ficheiro relevante. O identificador do commit permite registar com precisão a versão que decidiste utilizar.
Num repositório de exercício, git log --oneline -- mensagem.txt mostra commits relacionados com mensagem.txt. O nome é apenas um exemplo; substitui-o pelo caminho do ficheiro que estás a analisar. Procura uma mensagem que corresponda ao estado pretendido e guarda o identificador apresentado.
Podes consultar o conteúdo guardado com git show VERSAO_BOA:mensagem.txt, substituindo VERSAO_BOA pelo identificador real. Esta consulta permite verificar o texto antes de o repor. Não escrevas o nome do marcador como se fosse um commit existente no teu projeto.
Lê o conteúdo e confirma que corresponde ao que procuras. Uma mensagem de commit clara ajuda, mas não substitui essa verificação. Se estiveres a recuperar código, considera também as alterações de que ele dependia. Um ficheiro antigo pode referir uma função ou uma configuração que já não existe na versão atual.
Escolhe entre repor um ficheiro e desfazer uma alteração
Repor um ficheiro permite trazer o seu conteúdo de uma versão escolhida para o estado de trabalho. Desfazer um commit procura inverter as alterações desse commit através de um novo registo. A escolha depende do alcance do problema. Confirma quais os ficheiros e comportamentos envolvidos antes de decidir qual das operações corresponde ao teu objetivo.
| Necessidade | Operação a considerar | Verificação principal |
|---|---|---|
| Ler conteúdo antigo | Consultar com git show | A versão contém o que procuras |
| Repor um ficheiro | Restaurar a partir de uma origem explícita | Só o caminho pretendido foi alterado |
| Desfazer um commit | Criar uma reversão com git revert | O commit certo foi invertido |
| Recuperar a aplicação completa | Ensaiar código, dados e configuração | O serviço funciona no ambiente de recuperação |
Para um projeto partilhado, interessa que a correção seja compreensível para quem trabalha contigo. Uma nova alteração que documenta a recuperação permite perceber o que aconteceu e porquê. Evita escolher comandos de reescrita do histórico só porque parecem produzir um regresso rápido a uma data anterior.
Se o commit inclui várias mudanças independentes, desfazê-lo por inteiro pode retirar trabalho que queres manter. Nesse caso, identifica a correção necessária com mais detalhe. O objetivo de recuperação deve orientar a operação, e não ser adaptado ao primeiro comando que uma pesquisa ou um assistente sugerir.
Repõe um ficheiro num exercício controlado
Para aprender o processo, utiliza um repositório de exercício com um ficheiro simples e duas versões registadas. Confirma que o estado está limpo e que a versão escolhida contém o texto pretendido. Depois, restaura apenas esse ficheiro e observa a diferença. Assim, consegues compreender o efeito da operação com um âmbito pequeno e verificável.
A forma git restore --source=VERSAO_BOA --worktree -- mensagem.txt repõe o conteúdo desse caminho na pasta de trabalho a partir da origem indicada. Substitui o marcador pelo commit confirmado. Esta operação pode substituir alterações locais do ficheiro, pelo que o estado anterior tem de estar preservado antes de a executares.
Depois, usa git diff -- mensagem.txt e lê o ficheiro. O conteúdo restaurado ainda precisa de ser revisto e registado numa nova alteração, conforme o processo do projeto. A utilização explícita de --worktree neste exemplo distingue a edição dos ficheiros da preparação do próximo commit.
No ensaio local usado para conferir este artigo, um ficheiro de texto tinha uma mensagem inicial e uma segunda versão. A recuperação repôs os bytes da versão inicial e a diferença ficou visível para revisão. O ensaio verificou esse comportamento num repositório separado; não representa a recuperação de uma aplicação com base de dados ou integrações.
Desfaz um commit mantendo um registo da correção
Quando o problema corresponde a uma alteração registada que queres inverter, o Git permite criar uma reversão. O resultado acrescenta um novo commit ao histórico, em vez de fazer desaparecer o commit original. Antes de avançar, confirma a alteração escolhida e começa com o estado de trabalho limpo, como exige o uso normal desta operação.
Num caso simples, git revert COMMIT_A_DESFAZER aplica a inversão do commit identificado. O marcador deve ser substituído pelo identificador real da alteração problemática. Se o Git abrir um editor para a mensagem, conserva uma descrição que permita perceber qual a alteração desfeita e a razão da correção.
Podem surgir conflitos quando alterações posteriores interagem com o conteúdo que estás a inverter. Nesse caso, a operação exige revisão adicional. Não escolhas automaticamente uma versão de um ficheiro só para eliminar o conflito. Confirma o comportamento que deve permanecer e segue o processo de resolução adequado ao repositório.
O ensaio local deste artigo também verificou uma reversão simples, sem conflitos: foi criado um novo commit e o conteúdo anterior voltou a aparecer. O commit desfeito continuou no histórico. Esta evidência é limitada a esse exemplo; commits de integração e situações com dependências exigem uma análise própria.
Verifica o comportamento depois da recuperação
Uma recuperação só está pronta quando o resultado corresponde ao objetivo definido. Ler o histórico confirma a versão, mas não demonstra que a aplicação funciona. Revê as diferenças e executa as verificações relacionadas com o problema. Inclui também os comportamentos próximos que poderiam ser afetados pela reposição do ficheiro ou pela reversão escolhida.
No exemplo do formulário, confirma a mensagem apresentada após uma submissão válida. Verifica também o que acontece quando falta um campo obrigatório e se o botão continua a executar a ação correta. Se a alteração era apenas de texto, mantém o teste proporcional, mas não concluas a partir de uma captura de um ficheiro.
Compara os restantes ficheiros com o estado preservado. O menu e a ligação corrigida devem continuar como estavam, se essa era a condição inicial. Uma recuperação que resolve a mensagem e remove outra melhoria não cumpre o pedido completo. Regista qualquer diferença inesperada e esclarece-a antes de publicar.
Se o projeto tiver verificações automáticas relevantes, executa-as e lê o resultado. Distingue testes concluídos de testes que não conseguiste correr. O guia para transformar um protótipo em tarefas pequenas de implementação ajuda a definir alterações e critérios de aceitação que também facilitam recuperações futuras.
Separa o código dos dados e da configuração
O Git recupera o conteúdo que está guardado no repositório, mas uma aplicação pode depender de informação que vive noutros sistemas. Bases de dados, ficheiros enviados pelos utilizadores e configuração do ambiente precisam de tratamento próprio. Antes de considerar uma recuperação completa, identifica essas dependências e confirma quais as cópias disponíveis para cada uma.
Se uma alteração de código foi acompanhada por uma mudança na estrutura da base de dados, recuperar apenas o código antigo pode deixá-lo incompatível com os dados atuais. Essa situação pede um plano que considere ambas as partes. Não assumes que o alojamento desfaz alterações de dados só porque voltaste a uma versão anterior dos ficheiros.
Mantém segredos fora do histórico de código e documenta como são disponibilizados no ambiente autorizado. A pessoa que ensaia a recuperação precisa de saber que configuração falta, sem receber chaves copiadas para um documento partilhado. Um ficheiro de exemplo com nomes e valores fictícios pode explicar o contrato esperado.
Para um primeiro ensaio, lista o que consegues reconstruir a partir do repositório e o que depende de outra cópia. Depois, verifica uma aplicação simples num ambiente separado. As lacunas encontradas fazem parte do resultado: identificá-las antes de uma falha real é uma das razões para praticar a recuperação.
Confirma a versão que chega ao endereço público
Depois de validar a correção, acompanha o percurso de publicação usado no teu projeto. Um commit local, o envio para um repositório remoto e um deployment são momentos distintos. Regista a versão publicada e confirma o comportamento no endereço final. A conclusão deve indicar o que ficou efetivamente disponível para os utilizadores.
Se o alojamento publica automaticamente a partir de uma branch, conhece essa ligação antes de enviar a alteração. Uma correção aparentemente pequena pode desencadear um deployment. Se o projeto utiliza uma pré-visualização, aproveita-a para conferir o resultado antes da passagem para produção, de acordo com o processo já definido.
No site público, testa a página afetada e o percurso essencial. Confirma que estás a observar a nova versão e que não estás apenas a ver uma pré-visualização local. Guarda o identificador do commit e a referência do deployment quando a plataforma a disponibilizar.
Para trabalhar com um agente, explica desde o início se pretendes apenas diagnosticar, recuperar localmente ou também publicar. O artigo sobre dar contexto de negócio ao Claude Code ajuda a tornar estes limites claros. Uma tarefa bem definida reduz a distância entre o que pediste e o que foi executado.
Deixa o projeto mais fácil de recuperar da próxima vez
Depois de resolver o problema, melhora o registo que permitirá compreender futuras alterações. Commits com um objetivo claro, notas de validação e referências de publicação tornam a investigação mais simples. Não precisas de documentar cada tecla. Precisas de conservar informação suficiente para identificar uma versão conhecida e explicar como confirmar que ela funciona.
Uma mensagem como “corrige confirmação após envio do formulário” é mais útil do que “alterações finais”. Se a tarefa envolve vários comportamentos independentes, considera separá-los em alterações coerentes. Isso facilita tanto a revisão como a decisão de desfazer apenas uma parte mais tarde.
Acrescenta ao registo da recuperação o problema observado, a versão usada, os ficheiros afetados e as verificações concluídas. Se houve limitações, identifica-as. Um futuro colaborador deve conseguir distinguir uma recuperação testada de uma tentativa que apenas compilou sem erros.
Por fim, repete ocasionalmente um ensaio pequeno a partir das cópias autorizadas. O objetivo é comprovar que consegues reconstruir o que precisas, incluindo as dependências relevantes. Ter um histórico disponível é útil; saber utilizá-lo com um resultado verificado torna-o parte de um processo de trabalho mais fiável.
Aprende a gerir projetos no Laboratório da IA
No Laboratório da IA, podes aprender a construir com agentes e a manter controlo sobre versões, testes e publicação. As aulas semanais e os Zooms de acompanhamento semanais ajudam a esclarecer dificuldades concretas. Leva um exercício pequeno e explica o que queres recuperar, o que deve permanecer e como vais reconhecer o resultado correto.
Uma boa primeira prática é recuperar um ficheiro de texto num projeto de teste. Depois, aplica o mesmo raciocínio a uma alteração pequena da tua aplicação, com critérios de validação definidos.
Referências e verificação
A documentação oficial seguinte foi consultada em 14 de outubro de 2026. Os comandos de consulta, recuperação de um ficheiro e reversão simples foram ensaiados localmente num repositório separado, sem ligação a produção. O exemplo não cobre conflitos complexos, migrações de dados ou recuperação integral de serviços, que precisam de validação específica.
Aprende a construir isto no Lab.
Trabalha o processo com aulas, materiais e acompanhamento. Leva o que estás a construir e esclarece as dúvidas da tua implementação.
- Escolher entre consultar, restaurar um ficheiro e reverter um commit.
- Verificar a recuperação e separar código, dados e publicação.
- Praticar gestão de projetos nas aulas e Zooms semanais do Laboratório.
Aulas semanais para aprender e aplicar. Zooms de acompanhamento semanais para esclarecer dúvidas. Replay e materiais para retomar o trabalho ao teu ritmo.
Entrar no Laboratório da IA