Lovable ou Bolt estragou o app? Como voltar a uma versão anterior sem perder o que funcionava

Ilustração de painel de histórico de versões em ferramenta de desenvolvimento com IA
Resposta rápida

No Lovable, abra o painel History, pré-visualize a versão boa e use ‘Revert to this version’. No Bolt, abra o Version history (ícone de relógio), clique na versão e confirme em ‘Restore this version’ e depois ‘Restore version’. Nas duas ferramentas volta só o código: os dados do banco ficam como estão. Antes de um prompt arriscado, marque a versão boa (bookmark no Lovable, rótulo no Bolt) e conecte um repositório Git como backup fora da plataforma.

Fala aí, beleza? Tu manda um prompt inocente, tipo "melhora o layout do dashboard", e o app que funcionava de repente quebra a tela de login, some com um botão e por aí vai 😛

A boa notícia: dá pra voltar

A má notícia: nem tudo volta junto, e é exatamente isso que este post separa

O raciocínio é o mesmo de quando a gente fala de recuperar conversa perdida: primeiro entender o que é recuperável e o que não é, depois ir direto no caminho certo

Aqui o objeto recuperado é código gerado por IA, e o caminho muda entre Lovable e Bolt, então vou mostrar os dois separadamente

O que volta e o que não volta quando você reverte

Volta o código, não voltam os dados do banco

Essa é a regra que vale pras duas ferramentas, e entender isso antes evita MUITA dor de cabeça

O que volta:

  • No Lovable, o projeto inteiro no estado daquela versão (cada mudança gera uma versão automaticamente, não existe botão de salvar)
  • No Bolt, a versão do projeto que ele salvou automaticamente no Version history

O que não volta:

  • No Lovable, alterações de dados feitas depois daquela versão continuam no banco, o revert restaura o código e não toca nos dados
  • No Bolt, o restore não altera os bancos atuais do Bolt nem do Supabase

E tem um detalhe do Lovable que pega muita gente: o revert é tudo ou nada

Ele restaura o projeto inteiro pra aquela versão, sem escolher só um arquivo ou só um trecho

O lado bom é que nada se perde: as mudanças feitas depois daquele ponto continuam no chat e podem ser reaplicadas a qualquer momento 🙂

Isso tudo está na documentação de histórico do Lovable e no guia de rollback e backup do Bolt

Como voltar a uma versão anterior no Lovable

Pra voltar a uma versão anterior no Lovable, tu abre o painel History, pré-visualiza a versão boa e reverte pelo menu de ações dela

Se você ainda está pegando o jeito da ferramenta, vale dar uma olhada em como o Lovable funciona antes, mas o passo a passo é curtinho:

  1. Abra o painel History. Tem dois jeitos: pelo botão History na barra superior do editor ou pelo menu ao lado do campo de mensagem, escolhendo History. O painel tem duas abas: History (todas as versões) e Bookmarks (as que você marcou)
  1. Pré-visualize a versão candidata. Antes de reverter, abra a versão e veja no preview se é aquela que funcionava mesmo. Isso evita reverter pro ponto errado e ter que repetir o processo
  1. Reverta. No menu de ações da versão, escolha Revert to this version

Checagem: o preview mostra o app funcionando do jeito que estava antes do prompt que quebrou tudo

Erro comum deste passo: o botão de revert aparece desativado

Tem dois motivos possíveis: ou você já está naquela versão, ou a versão é antiga demais

No segundo caso, o tooltip mostra Cannot revert this far back in history, e a versão pode ser aberta e pré-visualizada, mas não restaurada

E se reverteu e quer tentar de novo? Massa, é justamente pra isso: dá pra voltar a um ponto anterior e mandar outra instrução a partir dali, sem perder o que foi feito depois (continua no chat)

Se o seu foco é só o Lovable e você quer o assunto mais destrinchado, tem também um post nosso sobre o que não volta junto no Lovable

Como restaurar uma versão anterior no Bolt

No Bolt o caminho recomendado pela própria documentação é o Version history, onde ficam as versões que ele salvou automaticamente

Se liga no passo a passo:

  1. Abra o Version history. Clique no ícone de relógio no menu superior
  1. Escolha a versão. Clique na versão desejada e o Bolt abre uma prévia dela
  1. Restaure. Clique em Restore this version, no canto superior direito, e confirme em Restore version

Checagem: a prévia antes do restore já mostra se aquela é a versão boa, então confira ali antes de confirmar

Tem também dois caminhos alternativos, segundo a documentação:

  • Rolar o histórico do chat e clicar na versão desejada
  • Baixar uma cópia local do projeto e restaurar pela conta StackBlitz

E se você está com medo de mexer no projeto atual? Tem um caminho sem risco 😀

Em Project settings existem backups com data e hora

Clicando em Load ao lado de um backup e confirmando em Create Fork, o Bolt cria uma cópia do projeto a partir daquele backup, sem afetar a versão atual

É tipo fazer um "salvar como" antes de mexer: o original fica intacto e tu testa na cópia

Erro comum deste passo: esperar que o restore desfaça o que aconteceu no banco

Ele não faz isso, os bancos do Bolt e do Supabase continuam como estão

Reverti e o app continua quebrado: o que pode ser

Na maioria dos casos o problema não está mais no código, e sim em algo que o revert não alcança

Bora ver os sintomas mais prováveis:

O código voltou, mas os registros ou as tabelas estão diferentes

Causa: o revert do Lovable e o restore do Bolt não tocam no banco

Se o prompt que quebrou o app também mexeu na estrutura ou nos dados, o código antigo pode estar conversando com um banco que já mudou

Solução: tratar os dados à parte, olhando direto no banco o que foi alterado depois daquela versão

Nenhuma das duas documentações descreve um jeito de voltar o banco junto com a versão, então não conte com o histórico de versões pra isso

No Lovable, a versão boa não pode ser revertida

Causa: ela é antiga demais, e por isso só aceita preview

Solução: pré-visualize a versão pra identificar o que funcionava e reaplique a partir do chat, ou recorra ao histórico no Git se o projeto estiver conectado a um repositório

No Bolt, mudanças feitas numa branch não aparecem na outra

Causa: cada branch tem memória própria, e o Bolt não faz merge de branches dentro do app

Solução: fazer o merge no GitHub

Pra não cair em nenhum desses de novo, o segredo é o ponto seguro, que é o próximo assunto

Como criar um ponto seguro antes de um prompt arriscado

Antes de pedir um redesign ou uma mudança grande, marque a versão que funciona, assim tu acha ela em segundos depois

No Lovable:

  1. Abra o painel History
  1. Na versão boa, clique no botão de bookmark

A própria documentação recomenda fazer isso antes de mudanças grandes, como um redesign ou uma reformulação do modelo de dados

No Bolt:

  1. Abra o Version history, passe o mouse sobre a versão boa e clique no ícone de lápis pra renomear (algo como "antes do redesign" já resolve)

Checagem: no Lovable, a versão aparece na aba Bookmarks; no Bolt, ela aparece no Version history com o rótulo novo

Erro comum deste passo: achar que o ponto seguro protege os dados do banco

Tome cuidado! Ele protege só o código, se o prompt arriscado vai mexer em dados, esse cuidado é separado

GitHub como rede de segurança fora da ferramenta

O histórico de versões vive dentro da ferramenta, e o Git é a cópia que fica fora dela

Se o projeto importa, vale ter as duas coisas

No Lovable: o código fica guardado dentro da plataforma, mas dá pra exportar e sincronizar com o GitHub

A Git sync do Lovable liga o projeto a um repositório (a documentação cita GitHub, GitLab e Bitbucket) e mantém os dois sincronizados automaticamente

Isso serve pra backup do código, pra colaboração por pull requests e pra trabalhar localmente na IDE com o projeto sincronizado

Se liga num detalhe: a sincronização é nos dois sentidos

O que tu edita no Lovable vai pro repositório, e commits enviados à branch sincronizada voltam pro Lovable

Ou seja, um commit zoado feito na IDE também chega no projeto, então cuidado com o que vai pra essa branch

No Bolt: conectar o GitHub faz backup do projeto com um histórico completo de mudanças guardado fora do Bolt

Dá pra importar um projeto existente do GitHub ou criar um repositório novo a partir do Bolt, e também criar branches no Bolt ou no GitHub

A própria documentação do Bolt sobre versões e GitHub faz uma separação que ajuda bastante a entender o papel de cada um:

  • Version history é pra voltar a cópias anteriores
  • Controle de versão como o GitHub também traz branches e recursos de colaboração

Se você conhece Git, pensa no Version history como um Ctrl+Z turbinado e no GitHub como o repositório de verdade 🙂

Mais conteúdo sobre ferramentas de IA para codar

Se você curte acompanhar as ferramentas de IA pra programar, aqui tem um vídeo sobre o DeepSeek Harness 2.0:

Vídeo complementar do canal Hora de Codar, sobre um assunto relacionado.

Antes do próximo prompt grande

O passo de agora é simples: abre o projeto que está funcionando e marca essa versão (bookmark no Lovable, rótulo no Bolt) antes de mandar qualquer mudança grande

Se o app já virou algo que você não quer perder, conecta um repositório Git também, assim existe uma cópia fora da ferramenta

E lembra: banco de dados é outro assunto, revert nenhum cuida dele por você

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.

Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Formações

Formação Vibe Coding

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 30min

Blog | Mais populares