Git essenziale per il vibe coder: branch, commit, revert, blame

Git è il safety net del vibe coding. Quando l’AI sbaglia, e succede, il modo in cui torni a uno stato pulito determina se il danno è di 5 minuti o di 5 ore. Conoscere 8 comandi Git essenziali è il prerequisito per sperimentare con coraggio: se sai annullare, puoi provare di più.

Perché questa lezione conta

Senza Git, ogni esperimento AI è un rischio. Hai paura di cancellare ciò che funzionava. Lavori in modo conservativo, perdi il vantaggio di velocità della generazione. Con Git, ogni stato è recuperabile. Ti puoi permettere di accettare un suggerimento, vedere se va, rifiutarlo se no. La lezione non è un tutorial Git completo: è il sottoinsieme essenziale per usare AI senza paura.

Obiettivo operativo

Alla fine devi saper:

1. usare branch per isolare esperimenti AI;
2. fare commit piccoli e tornare indietro velocemente quando serve;
3. usare blame e log per capire storia senza fare archeologia.

Nucleo della lezione

1. Branch per isolare esperimenti

Concetto: ogni esperimento AI vive in un branch separato. Main resta stabile. Se l’esperimento va bene, merge. Se no, scarta il branch.

Comandi base:

• git checkout -b feat/nome-task — crea nuovo branch e ci passa sopra.
• git branch — lista branch.
• git checkout main — torna su main.
• git branch -D feat/abbandonato — elimina branch (locale) anche se non mergiato.
• git push -u origin feat/nome-task — spinge il branch su remoto la prima volta.

Convenzione naming: feat/, fix/, refactor/, chore/ come prefisso. Aiuta a distinguere il tipo di lavoro.

Pratica per agenti: prima di lanciare un agente CLI, sempre branch dedicato. Non lanciare agenti su main.

2. Commit come checkpoint

Concetto: ogni stato funzionante che vuoi poter ricuperare = commit. Commit piccoli, frequenti, con messaggio sensato.

Comandi base:

• git status — cosa è cambiato.
• git diff — diff non staged.
• git diff --staged — diff staged.
• git add file.ts — stage di un file specifico (preferibile a git add .).
• git add -p — stage interattivo, scegli pezzi (utile per separare modifiche).
• git commit -m "..." — commit.
• git log --oneline -10 — ultimi 10 commit in formato compatto.

Conventional Commits (raccomandato): <tipo>(<scope>): <descrizione>.

Esempi:

• feat(auth): aggiungi login con magic-link
• fix(form): valida email server-side per evitare bypass client
• refactor(utils): estrai formatPrice in modulo dedicato
• docs(agents): aggiorna comandi build dopo migrazione a bun

Messaggio commit dovrebbe rispondere “perché”, non solo “cosa”. Il “cosa” è leggibile dal diff.

3. Revert e reset: tornare indietro

Tre modi diversi di “annullare”, ognuno per situazione diversa:

git restore <file>: scarta modifiche non committate su un file. Recupera versione dell’ultimo commit. Utile quando l’AI ha modificato file che non volevi.

git reset --hard HEAD: scarta tutte le modifiche non committate. Torna esattamente allo stato dell’ultimo commit. Utile dopo sessione AI andata male prima del commit.

git reset --hard HEAD~1: cancella ultimo commit e torna allo stato precedente. Distrugge l’ultimo commit. Solo se non è già pushato a remoto condiviso.

git revert <commit>: crea un nuovo commit che annulla un commit precedente. Non distrugge storia, sicuro per branch condivisi.

Regola: prima di reset, valuta cosa stai distruggendo. Se sei su branch personale e non condiviso, reset è ok. Se condiviso, revert.

Pre-condizione importante: se hai modifiche non committate che vuoi tenere ma il branch è in stato confuso, git stash salva le modifiche da parte. Recuperi con git stash pop.

4. Blame e log per capire storia

Quando un bug appare e non sai da dove viene:

git log --oneline file.ts: storia di un file. Quali commit lo hanno toccato.

git blame file.ts: chi ha scritto cosa, riga per riga. Output: hash commit + autore + data per ogni riga.

git show <commit>: cosa è cambiato in un commit specifico, con diff completo.

git log -S "stringa": trova commit che hanno aggiunto/rimosso una specifica stringa di codice. Utile per “quando è stata introdotta questa funzione?”.

git bisect: bisezione binaria su commit per trovare quale ha introdotto un bug. Avanzato ma potente.

Importante: git blame non è giudizio personale. È strumento di archeologia. “Chi ha scritto questa riga” = “in quale commit è stata aggiunta”, non “chi è da incolpare”.

Su progetti con AI: blame mostra il committente umano, non il modello che ha generato. Pratica: in commit message rilevanti, segnala se il codice è stato generato e accettato (es. Co-Authored-By: Claude).

Procedura pratica

Workflow quotidiano con Git + AI:

1. Inizio sessione: git status (deve essere pulito), git pull se collaborativo.
2. Branch nuovo: git checkout -b feat/task-piccolo.
3. Lavoro AI: genera, leggi diff, accetta o rifiuta.
4. Commit periodici: dopo ogni passo verificato, git add ... + git commit -m "...".
5. Se va male: git reset --hard HEAD (perdi solo modifiche non commit) o git restore <file> per file specifici.
6. Push periodico: git push per backup remoto.
7. A fine task: PR (pull request) o merge in main + delete branch.

Laboratorio guidato

Simulazione completa:

Step 1: git checkout -b feat/lab-git. Stato: pulito.

Step 2: chiedi a un’AI di creare una funzione utility (es. formatPrice). Accetta diff. git add + git commit -m "feat(utils): aggiungi formatPrice".

Step 3: chiedi all’AI di aggiungere test. Accetta. git add + git commit -m "test(utils): aggiungi test per formatPrice".

Step 4: chiedi di “migliorare il modulo”. L’AI fa refactor laterale che rompe altre cose. Diff lungo, fuori scope.

Step 5: prima di committare, git restore . (annulla tutto). Tornato a fine step 3.

Step 6: chiedi di fare la stessa modifica con scope ristretto e cambia approccio.

Step 7: git log --oneline mostra storia pulita di 2 commit. Stato finale: come desideravi.

Pratica esattamente questo flusso una volta. Memorizza i comandi.

Output atteso

Una sequenza minima di comandi Git stampata o salvata in ~/.config/cheatsheet/git.md:

# Inizio task
git checkout -b feat/task

# Durante lavoro AI
git status
git diff
git restore <file>     # scarta modifiche su file
git reset --hard HEAD  # scarta tutto non committato

# Salva passo verificato
git add <file>
git commit -m "tipo(scope): descrizione"

# Fine task
git push -u origin feat/task

# Capire storia
git log --oneline -20
git blame <file>
git show <hash>

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: usare Git come memoria affidabile e rete di sicurezza durante il lavoro con AI. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Branch per isolare esperimenti, commit per salvare punti buoni, diff per rivedere, revert per tornare indietro.
• Messaggi di commit come narrazione tecnica: cosa è cambiato e perché.
• Blame e log per capire storia del codice senza attribuire colpe personali.

3. Applicazione: svolgi il laboratorio: creare un branch, fare due commit piccoli, introdurre un errore e recuperare con revert o nuova correzione. L’output da ottenere è: una sequenza minima di comandi Git per lavorare con AI senza paura di sperimentare.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho un branch dedicato per ogni sessione AI significativa;
• faccio commit piccoli (uno per passo verificato);
• scrivo messaggi commit nel formato Conventional Commits;
• so distinguere restore, reset --hard, revert;
• uso git blame/log per capire storia, non per giudicare;
• pusho a remoto regolarmente per backup.

Errori comuni

Lavorare su main. Esperimento va male = main rotto. Sempre branch dedicato.

Commit gigante a fine giornata. “Salviamo tutto in un commit”. Storia inutilizzabile, revert impossibile.

Messaggio “update” o “wip”. Tre commit “update” = tre commit invisibili. Messaggio che dice il perché.

git add . cieco. Aggiunge file non voluti (file generati, log, secrets). Preferisci git add file.ts.

git push --force su branch condiviso. Distrugge lavoro altrui. Solo su branch personali, se necessario.

Niente backup remoto. Disco fail = lavoro perso. Push regolare anche su progetti personali.

Confondere revert con reset. Revert crea commit, è sicuro su branch condivisi. Reset distrugge storia, solo branch personali.

Prompt di lavoro

Per messaggio commit:

Diff dei cambiamenti:
[output di `git diff --staged`]

Genera commit message in formato Conventional Commits in italiano.

Vincoli:
- soggetto: max 70 caratteri, presente, "perché" sintetico
- formato: tipo(scope): descrizione
- tipi ammessi: feat, fix, refactor, docs, test, chore, style, perf
- corpo (opzionale): solo se "perché" non è ovvio dal soggetto, max 3 righe

Output: solo il messaggio, niente altro.

Esercizio finale

Per la prossima settimana di lavoro AI, mantieni rigore:

1. ogni task = nuovo branch;
2. ogni passo verificato = commit;
3. nessun task senza pull request finale;
4. usa git restore/reset quando l’AI sbaglia, senza colpa.

A fine settimana guarda la cronologia: 20-40 commit piccoli, branch chiari, niente “fix mistakes”. Quel ritmo è ciò che permette di lavorare con AI con velocità senza accumulare disordine.