Foto, disastro, ripristino: git in cinque minuti

La consegna

Metti il mini-sito del capitolo 4.3 sotto git usando Claude Code, poi fai una modifica volutamente brutta — sfondo fucsia, tanto è una prova — e ripristina la versione precedente. Cinque minuti, e alla fine hai un gesto in più nelle mani: tornare a ieri. Qui trovi la sequenza esatta, l'ordine che non si può invertire e le due righe del prompt che evitano di perdere lavoro mentre torni indietro.

Come si ragiona

1. Non stai imparando git, stai comprando una risposta. La domanda «e se rompe tutto?» oggi ti costa prudenza: rileggi ogni modifica due volte, approvi con l'indice sospeso, rimandi i lavori grossi. Dopo questo esercizio la risposta è «torno indietro di trenta secondi», e la prudenza torna a essere attenzione invece che freno. Tre concetti bastano: il repository è l'album del progetto, ogni commit è una foto con la didascalia, il ripristino è tornare a quella foto.

2. Un prerequisito: git. Su Windows va installato a mano ed è Git for Windows, il download consigliato nel capitolo 4.2; su Mac e Linux di solito c'è già. In ogni caso non devi controllarlo tu: se manca, il primo passo di P243 si ferma lì e ti dice come installarlo sul tuo sistema — comportamento corretto, non un errore: il prompt controlla prima di agire.

3. L'ordine non si inverte: prima la foto, poi il disastro. È l'unico passaggio in cui l'esercizio può fallire davvero. Chi rompe prima e fotografa dopo si ritrova con una sola versione salvata — quella fucsia — e niente a cui tornare. La sequenza è: metti sotto git con la prima foto, verifica che la foto esista, poi rovina la pagina.

4. Il disastro dev'essere visibile a occhio nudo. Lo sfondo fucsia è la scelta giusta proprio perché è volgare: la vedi ricaricando la pagina, senza aprire un file, senza confrontare righe di codice. Se per accorgerti della modifica devi ispezionare style.css, non stai collaudando il ripristino — stai collaudando la tua vista.

5. Il ritorno si fa in due tempi, e il secondo parte su tua conferma. Prima l'elenco delle versioni salvate con data, ora e didascalia, la proposta motivata di quale ripristinare e cosa si perde tornando indietro. Solo dopo il tuo «ripristina», l'esecuzione. Il motivo è nella riga successiva.

6. La riga che salva le giornate è l'avviso sulle modifiche non salvate. Git protegge solo ciò che hai fotografato. Se al momento del ripristino hai lavoro fatto e non ancora salvato in un commit, un ritorno cieco se lo porta via. P244 impone l'avviso in maiuscolo e la proposta di fotografare prima. Quando compare, ti fermi e decidi in una riga: se quel lavoro ti serve, prima la foto e poi il ritorno; se è proprio la modifica che stai buttando — il fucsia di questo esercizio — vai avanti.

7. La verifica si fa con gli occhi, nel browser. Ricarichi la pagina: deve essere tornata color sabbia. Se resta fucsia mentre il file dice il contrario, non è git che ha fallito: è il browser che ti mostra la versione vecchia del foglio di stile tenuta in memoria. Ricarica forzata e la questione si chiude.

8. Conosci anche i limiti del paracadute. Copre solo ciò che hai fotografato — quindi il commit a fine sessione diventa un'abitudine — e copre solo quella cartella: i file fuori dal progetto restano senza rete, e per loro valgono i livelli 0 e 1, la copia e la cartella-prova.

Una soluzione svolta

Cartella sito-marta, Claude Code lanciato lì dentro. Primo passo, P243:

Metti questa cartella sotto controllo di versione con git, e trattami da
non-tecnico: niente gergo senza traduzione.
Passi:
1) controlla che git sia installato; se manca, dimmi come installarlo sul mio
   sistema e fermati lì;
2) verifica che la cartella non sia già sotto git: se lo è, dimmelo e non
   inizializzare nulla di nuovo;
3) se ci sono file che non ha senso fotografare, proponimi l'elenco delle
   esclusioni e aspetta il mio ok;
4) crea il repository e il primo commit con didascalia «Prima versione: mini-sito
   di Marta, palette sabbia e verde bosco, FAQ corrette»;
5) spiegami cosa hai appena fatto con l'analogia dell'album fotografico, dove vive
   l'album e cosa non devo mai fare a mano lì dentro;
6) chiudi con la frase esatta da dirti d'ora in poi per «scattare una foto» a fine
   lavoro.
Regole: tutto resta sul mio computer — niente GitHub, niente server; non eliminare
né spostare alcun file esistente.

Esito: git c'è, la cartella non era ancora sotto controllo, viene proposta l'esclusione della sottocartella delle copie di sicurezza creata nel 4.3 (giusta: fotografare copie di ciò che stai già fotografando è rumore). Album creato, prima foto scattata. La frase di chiusura da riusare è semplice: «salva una versione con la didascalia: …».

Secondo passo, il disastro:

Cambia lo sfondo della pagina in fucsia acceso. È una prova, non spiegarmi
che è brutto.

Ricarichi il browser: la pagina di Marta è diventata una cosa che nessun cliente dovrebbe vedere. Perfetto, è lo scopo.

Terzo passo, il ritorno, con P244:

Devo tornare indietro: voglio riportare il progetto a una versione precedente.
Cosa è successo: ho cambiato lo sfondo in fucsia per prova.
Dove voglio tornare: alla versione di prima, quella con la palette sabbia.
Procedi in due tempi, e il secondo parte solo su mia conferma.
TEMPO 1 — mostrami, senza toccare nulla:
1) l'elenco delle versioni salvate: data, ora e didascalia, dalla più recente;
2) la versione che proponi di ripristinare e perché è quella giusta;
3) cosa cambierebbe esattamente: quali file tornano indietro e cosa perdono;
4) se ci sono modifiche non ancora salvate in un commit, avvisami in maiuscolo:
   dimmi quali sono e proponi di fotografarle prima.
TEMPO 2 — solo dopo il mio «ripristina»: esegui, poi dimmi come verificare con i
miei occhi che il progetto sia tornato a quella versione.
Regole: mai comandi che cancellano la storia o il lavoro non salvato; se il
ripristino che chiedo è rischioso, spiegami perché e proponi la via reversibile.

Nel Tempo 1 l'elenco mostra una sola foto — «Prima versione: mini-sito di Marta…» — e l'avviso in maiuscolo scatta: la modifica fucsia non è mai stata salvata. Che in questo caso è esattamente ciò che vuoi, ma leggerlo insegna il riflesso. Ripristino confermato, style.css torna indietro, index.html non viene toccato perché non era cambiato. Ricarica: sabbia e verde bosco. Quattro minuti.

Come capisci di averlo fatto bene

• Prima della modifica brutta l'elenco delle versioni conteneva già almeno una foto. Se era vuoto, hai collaudato un paracadute che non c'era.
• Lo sfondo fucsia lo hai visto davvero nel browser: senza il prima e il dopo a occhio, il ripristino non dimostra nulla.
• Dopo il ripristino la pagina ricaricata è tornata come la ricordavi, e il resto della pagina è intatto: testi, prezzi, FAQ.
• Nella cartella non manca nessun file: un ripristino riporta indietro il contenuto, non elimina il progetto.
• Sai ripetere la sequenza a memoria, senza questa pagina davanti: foto → modifica → elenco delle versioni → ripristino → verifica nel browser.

L'errore che fanno quasi tutti

Fare prima la modifica brutta e poi mettere sotto git. L'entusiasmo è comprensibile — il fucsia è la parte divertente — ma a quel punto l'unica versione fotografata è quella rovinata, e il ripristino riporta al disastro. Non si perde nulla di grave sul mini-sito di prova; si perde l'abitudine giusta, che sul lavoro vero costa cara. La correzione è una regola di tre parole da applicare sempre, non solo qui: prima la foto. Vale per ogni sessione che sta per toccare file che ti importano.

E adesso

La Parte 5 toglie il terminale e tiene la potenza: Cowork, per delegare lavoro d'ufficio su cartelle vere. Prima di lasciarla, prendi la checklist «Automazione sicura» dell'Appendice C: unisce le sei spunte di questo capitolo ai punti di controllo umano del 5.4, e vale per ogni flusso nuovo. I prompt: P243 — go.totaliweb.com/p243 per mettere sotto git, P244 — go.totaliweb.com/p244 per tornare indietro, P241 — go.totaliweb.com/p241 per il piano prima del lavoro, P242 — go.totaliweb.com/p242 per il riepilogo delle modifiche a fine sessione.