Versionamento e backup: non perdere mai il lavoro fatto

Nella lezione precedente abbiamo collegato Lovable a GitHub. Ma GitHub non è l'unico strumento che hai a disposizione per non perdere lavoro: Lovable tiene già, in automatico, una cronologia interna di ogni modifica al progetto. Questa lezione chiude il modulo mettendo a fuoco la differenza tra i due strumenti, perché non sono la stessa cosa, e usarli insieme è più solido che affidarsi a uno solo.

## In breve

Secondo la documentazione ufficiale, ogni modifica che Lovable fa al tuo progetto crea automaticamente una versione: non esiste un pulsante "salva", la cronologia è sempre completa e aggiornata, e puoi tornare a qualsiasi versione precedente in qualsiasi momento. Questa cronologia vive dentro Lovable e copre il codice del progetto. Un repository GitHub collegato, invece, è una copia indipendente che vive fuori da Lovable, con la propria cronologia di commit. Sono due reti di sicurezza diverse, e coprono rischi diversi.

Che cos'è il versionamento in Lovable

Il pannello Cronologia dell'editor Lovable elenca ogni versione del progetto, generata automaticamente a ogni modifica. Come spiega la documentazione Lovable, ha due schede: Cronologia, che elenca tutte le versioni, e Preferiti, che elenca le versioni che hai contrassegnato come tali. Cliccando su una versione la apri in anteprima senza modificare nulla; da lì puoi vedere esattamente quali righe di codice sono cambiate, tornare al punto della conversazione che ha generato quella versione, oppure ripristinarla.

Lo conferma la documentazione: la versione attualmente visibile ai tuoi utenti mostra un'etichetta "Pubblicato", utile per capire subito qual è lo stato live rispetto a quello su cui stai lavorando in editor.

Cosa NON è

Il ripristino di una versione precedente (Revert) non è distruttivo per la chat: lo indica la guida ufficiale, la conversazione continua da dove sei, e le modifiche fatte dopo il punto a cui torni restano comunque visibili nella chat, pronte per essere riapplicate in seguito se cambi idea.

Ma soprattutto, il ripristino non tocca mai i dati del tuo database. È la distinzione più importante da tenere a mente: come spiega la documentazione ufficiale, il ripristino restituisce solo il codice del progetto e ridistribuisce le edge function per farle corrispondere a quella versione, non ripristina né annulla le modifiche ai dati; se dei messaggi successivi a quella versione hanno aggiunto record, modificato dati o eseguito migrazioni, ripristinare il codice non annulla quei cambiamenti ai dati.

Infine, la cronologia interna di Lovable non è un backup indipendente nel senso pieno del termine: vive dentro l'account e la piattaforma Lovable. Per una copia realmente esterna, con una cronologia di commit tracciabile fuori da Lovable, serve il repository GitHub visto nella lezione precedente. Lo chiarisce la documentazione GitHub: ogni commit ha un identificativo unico, un messaggio descrittivo e un autore e una data associati.

Come funziona

Ci sono anche i Preferiti (bookmark): puoi contrassegnare una versione che consideri stabile, prima di iniziare un cambiamento importante, ad esempio, così da poterla ritrovare rapidamente senza scorrere tutta la cronologia. Lo specifica la pagina ufficiale: la versione, se molto vecchia, può essere ancora aperta e vista in anteprima, ma non più ripristinata, in quel caso il pulsante Revert mostra "Cannot revert this far back in history". Lo stesso vale per i progetti nati da un "remix" di un altro progetto sul backend integrato di Lovable: le versioni precedenti al remix non sono ripristinabili.

Sul lato GitHub, ogni sincronizzazione produce commit reali con cronologia Git standard, consultabile e confrontabile su GitHub indipendentemente da cosa succede dentro Lovable, è la parte che rende questo backup davvero "esterno".

## Perché conta

Sperimentare senza paura è probabilmente il beneficio più immediato: sapere che ogni versione resta recuperabile toglie l'ansia di "rompere qualcosa" mentre provi una modifica importante. Ma la ragione più seria è più semplice: nessuna piattaforma, per quanto affidabile, è un'assicurazione contro ogni imprevisto, un problema con l'account, un cambio di piano, un errore umano. Avere il codice anche su un repository che controlli tu direttamente è la differenza tra "spero non succeda nulla" e "ho comunque una copia".

## Esempio lampante

Caso ipotetico. Uno studio dentistico ha un sito di prenotazione appuntamenti costruito con Lovable, con il calendario disponibilità collegato a un database di pazienti.

### INPUT

la persona che gestisce il sito decide di rifare da zero la sezione di prenotazione per renderla più semplice da usare da smartphone, un cambiamento che tocca diverse pagine contemporaneamente.

### ANALISI

prima di iniziare, contrassegna come preferita la versione attuale, funzionante, del progetto. A metà lavoro, il nuovo flusso di prenotazione smette di salvare correttamente gli appuntamenti: qualcosa nella logica si è rotto.

### DECISIONE

apre il pannello Cronologia, individua la versione salvata come preferita prima di iniziare, e clicca Ripristina. Sa già, perché lo ha letto in questo corso, che il ripristino riporta solo il codice: gli appuntamenti già salvati nel database durante i test restano lì, quindi controlla anche quelli manualmente prima di riaprire le prenotazioni al pubblico.

### OUTPUT

il sito torna al comportamento funzionante in pochi minuti, senza dover ricostruire nulla da zero. Avendo anche GitHub collegato dalla lezione precedente, lo studio ha in aggiunta una copia del codice, comprese le versioni intermedie del tentativo fallito, consultabile fuori da Lovable, se mai dovesse servire capire cosa esattamente non ha funzionato.

Come farlo

1. Prima di ogni cambiamento importante, contrassegna come preferita la versione attuale dal pannello Cronologia, un redesign, una modifica alla logica di pagamento, qualsiasi cosa che tocca più parti del progetto insieme.
2. Dopo modifiche rilevanti, apri l'anteprima della nuova versione prima di continuare, per verificare che il comportamento sia quello atteso.
3. Se qualcosa si rompe, apri la Cronologia, individua la versione buona e clicca Ripristina, confermando la data mostrata per essere sicuro di tornare al punto giusto.
4. Ricorda sempre che il ripristino riguarda solo il codice: se il problema ha toccato anche i dati (record creati, migrazioni eseguite), va gestito separatamente, il ripristino da solo non lo risolve.
5. Collega il progetto a GitHub (visto nella lezione precedente) per avere, oltre alla cronologia interna, una copia realmente indipendente del codice.
6. Sui piani a pagamento, scarica periodicamente il codice del progetto dall'editor come ulteriore rete di sicurezza, oltre a cronologia e GitHub.

## Errori comuni

Considerare la cronologia automatica di Lovable già un backup esterno sufficiente. Riduce il rischio di errori quotidiani, ma resta dentro la stessa piattaforma: non protegge da problemi che riguardano l'account o la piattaforma stessa.

Aspettarsi che il ripristino di una versione recuperi anche i dati

Non lo fa mai: tocca solo il codice. È l'errore più costoso da scoprire tardi, quando si dà per scontato che "tornare indietro" risolva anche eventuali dati persi o corrotti.

Fare il bookmark di una versione stabile solo dopo che qualcosa si è già rotto

Il momento giusto è prima di iniziare un cambiamento importante, non dopo.

Non collegare mai GitHub perché "tanto Lovable salva tutto"

Salva tutto dentro Lovable, è comunque un solo posto dove tutto può, in teoria, andare storto insieme.

Quando conta meno

Per un esperimento veloce, senza dati sensibili e senza intenzione di portarlo mai in produzione, la sola cronologia automatica di Lovable è già più che sufficiente: collegare GitHub e organizzare bookmark per un progetto che butterai tra una settimana è un livello di cautela superiore a quello che serve davvero.

## In sintesi

Lovable tiene automaticamente una cronologia completa di ogni versione del progetto, con la possibilità di vedere le differenze, tornare a versioni precedenti e contrassegnare quelle stabili, ma il ripristino tocca solo il codice, mai i dati del database, e resta comunque dentro la stessa piattaforma. Un repository GitHub collegato aggiunge una copia realmente indipendente, con la propria cronologia di commit. Usati insieme, coprono rischi diversi: errori quotidiani nel lavoro di ogni giorno, e imprevisti più seri che riguardano l'account o la piattaforma stessa.

## Cosa imparare dopo

Con questa lezione si chiude il modulo su GitHub e gestione del progetto: da cosa sia GitHub, a come collegarlo davvero a Lovable, fino a come usare insieme cronologia interna e backup esterno per non perdere mai il lavoro fatto. Il modulo successivo del corso porta questi stessi strumenti oltre il prototipo, verso cosa serve davvero per portare un progetto Lovable in produzione come prodotto reale.

---

Vuoi provarlo?

Prova Lovable →

Link di affiliazione: se ti iscrivi da qui, ricevo una piccola commissione, a te non cambia nulla.