O Lovable estragou o projeto: como voltar a uma versão anterior e o que não volta junto?

Fala aí, beleza? Se o último prompt destruiu o app que estava funcionando, respira: dá pra voltar sim 🙂

No Lovable, toda alteração gera uma versão automaticamente, sem botão de salvar, e o histórico fica sempre completo e atualizado

Completo aqui quer dizer que nenhuma versão some, mas não que todas possam ser restauradas: as muito antigas só dão pra visualizar (já já tu entende o porquê)

O cenário é clássico no vibe coding: tu pede um ajuste pequeno, a IA resolve reescrever metade do app e aquilo que funcionava some

Só que tem uma ressalva IMPORTANTE logo de cara: a reversão traz o código de volta, mas não traz os dados do banco

Bora ver o que volta, o que não volta e como se proteger antes do próximo prompt grande?

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Como voltar a uma versão anterior no Lovable pelo histórico de versões

O caminho é o painel History, que a documentação oficial chama de version history (histórico de versões)

Ele tem duas abas: History, com todas as versões, e Bookmarks, com as que você marcou

1. Abra o painel History: clique no botão History na barra superior do editor, ou no menu ao lado do campo de mensagem e escolha History

2. Inspecione a versão em modo snapshot: clique em uma versão da lista e ela abre em modo snapshot, onde dá pra navegar por aquele estado do app sem alterar nada. Pra sair, use o botão Back to latest, na barra superior, que leva de volta à versão atual

Erro comum deste passo: pular a inspeção e reverter direto. Aí tu escolhe uma versão em que o bug já existia e fica pulando de versão em versão 😛

3. Reverta para a versão boa: cada versão tem um botão Revert, e também dá pra restaurar a partir do próprio modo snapshot

Resultado esperado: o código do projeto fica como estava naquela versão (os dados do banco não voltam junto, isso fica pra próxima seção)

E se tu se arrepender? Tranquilo, reverter não apaga nada

As mudanças feitas depois daquele ponto continuam no chat e podem ser aplicadas de novo quando você quiser

Checagem final: navegue pelo app restaurado e confira se a funcionalidade que tinha quebrado voltou a funcionar

Reverti o projeto e os dados não voltaram: o que acompanha a reversão e o que não acompanha

Isso é esperado: a reversão no Lovable restaura só o código, não o banco

Sintoma: o código voltou, mas registros, tabelas ou dados alterados depois daquela versão continuam no estado novo

Causa: pela documentação do histórico, reverter restaura o código do projeto e faz o redeploy das edge functions pra acompanhar

Os dados do banco não são restaurados, então a reversão não desfaz mudanças de dados feitas depois daquela versão

E os secrets? Que secrets?

São os valores sensíveis (chaves de API, tokens, credenciais) que ficam fora do código, criptografados, injetados nas Edge Functions e nunca chegam ao navegador. Eles moram na seção Secrets do Cloud tab

A documentação do histórico não fala de secrets, então não dá pra afirmar se o Revert mexe neles ou não

O mesmo vale pra configurações externas (domínio, provedores de login, integrações de terceiros, publicação): a página de history não cobre isso, então confira cada uma depois de reverter

Como recuperar os dados no Lovable Cloud

Se o projeto usa Lovable Cloud, existe um backup diário do banco, guardado por até cerca de 14 dias

Ele fica em Cloud tab > Database > Backups, conforme a documentação do banco

O botão Restore to this backup, com confirmação, volta o banco para aquele ponto, incluindo schema e dados

Tome cuidado! Antes de clicar, leve em conta três coisas:

• A restauração é permanente: tudo que foi criado ou alterado depois do backup escolhido se perde
• O banco fica indisponível por alguns minutos durante o processo
• Como o schema também volta, o app pode deixar de bater com o banco

Pra esse último caso, a própria documentação orienta pedir ao Lovable no chat que teste o app e corrija as incompatibilidades

Quem pode restaurar? Qualquer pessoa com acesso de edição ao projeto, e no plano Enterprise cada restauração fica registrada no audit log do workspace

Como prevenir: marque a versão boa com Bookmark antes de mexer no modelo de dados, assim tu sabe exatamente pra onde voltar no código

Supabase próprio: por que a reversão não desfaz o schema

Porque, no Supabase próprio, o schema muda via migrations que já rodaram no seu banco, e migration não tem desfazer automático

Sintoma: depois do Revert, o banco no Supabase externo continua com as tabelas e colunas novas

Causa: na integração com Supabase, as mudanças de schema rodam como migrations revisadas

O Lovable escreve o SQL, mostra e pede aprovação no chat

Depois de aprovado, executa no seu projeto Supabase, salva o arquivo em supabase/migrations/ e regenera os tipos TypeScript

E as migrations do Supabase só andam pra frente: não existe migration "down" que desfaça o SQL

Solução: escrever uma nova migration que reverta as mudanças

Tome cuidado! Cada projeto Lovable se conecta a um único Supabase, mas vários projetos Lovable podem usar o MESMO Supabase (tipo o app do cliente e um painel admin)

Ou seja, desfazer o schema pra consertar um app pode quebrar o outro que divide o banco

Outro detalhe: se o projeto usa Lovable Cloud, depois de ativado ele não pode ser desconectado nem trocado por uma conexão com Supabase externo

Como prevenir: leia o SQL antes de aprovar a migration no chat, é ali que dá pra barrar a mudança antes dela virar problema

Aparece "Cannot revert this far back in history": o que fazer

Essa mensagem quer dizer que a versão é antiga demais pra ser restaurada, só pra ser vista

Sintoma: ao tentar reverter, aparece Cannot revert this far back in history

Causa: todas as versões ficam guardadas, mas as muito antigas só podem ser abertas e visualizadas

A documentação não informa a partir de quando uma versão fica longe demais

Tem um caso parecido: em um projeto Cloud remixado, não dá pra reverter pra versões anteriores ao remix (as criadas depois do remix revertem normalmente)

Solução: dá pra seguir por dois caminhos

• Abrir a versão em modo snapshot, ver como o app se comportava e pedir ao Lovable no chat que reaplique aquele comportamento
• Se o Git sync já estava ativo, o histórico de commits do repositório guarda aquele código, e como a sincronização é nos dois sentidos, commits enviados pra branch sincronizada voltam pro projeto

Como prevenir: Bookmarks e Git sync, que é justamente o próximo assunto

Como evitar perder uma versão boa: Bookmark e sincronização com o GitHub

A prevenção é marcar as versões estáveis e manter o código num repositório seu, lembrando que nenhum dos dois protege dados do banco

O que volta depende do que foi guardado, e o que ninguém guardou não tem mágica que traga de volta

1. Bookmark na versão estável: cada versão tem um botão Bookmark que a guarda na aba Bookmarks. A documentação recomenda fazer isso antes de mudança grande, como um redesign ou uma reformulação do modelo de dados

2. Ative o Git sync: ele mantém o código num repositório seu no GitHub ou GitLab, conforme a visão geral do Git sync. O que tu edita no Lovable vira commit, e commits na branch sincronizada voltam pro projeto

Se liga em duas limitações: vincular cria um repositório novo, e não dá pra importar um repo do GitHub que já existe (a conexão só funciona exportando do Lovable pra lá)

E o Lovable edita e sincroniza uma branch por vez: commits em outras branches só aparecem depois do merge na branch sincronizada ou se tu trocar a branch sincronizada

3. Confira o backup antes de mexer no schema: no Lovable Cloud, olhe em Cloud tab > Database > Backups se existe um backup recente

Erro comum: achar que o repositório também protege os dados

O Git guarda código, não o conteúdo do banco, então Git sync sem backup ainda deixa os dados descobertos

Vídeo de apoio

Se tu tá usando o Lovable no dia a dia, esse vídeo do canal Hora de Codar fala sobre estratégia pra não gastar créditos à toa na ferramenta

Antes do próximo prompt grande

Abre o History agora, encontra a versão que está funcionando e marca ela com Bookmark

Se o Git sync ainda não está ativo, ativa antes de pedir a próxima mudança grande

E se o projeto usa banco no Lovable Cloud, dá uma olhada em Cloud > Database > Backups pra saber qual é o backup mais recente, assim tu sabe até onde consegue voltar se der ruim 😀

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.