Capstone: storia ripulita, workflow scelto, recupero da disastro

Il capstone chiude il corso trasformando i comandi Git in un sistema di lavoro. Non devi dimostrare di ricordare opzioni a memoria: devi prendere un repository, valutarne lo stato, scegliere un workflow, pulire una storia locale e dimostrare di saper recuperare da un errore controllato.

L’obiettivo è uscire con una policy Git applicabile al tuo progetto.

Perché questa lezione conta

Git non è utile perché ha molti comandi. È utile quando il team sa rispondere con sicurezza a domande operative:

1. da quale branch parte il lavoro?
2. come si scrive un commit?
3. quando si apre una PR?
4. come si pubblica una release?
5. cosa succede se qualcuno resetta il branch sbagliato?
6. quali controlli sono locali e quali in CI?

Senza queste risposte, anche sviluppatori esperti finiscono per improvvisare.

Obiettivo operativo

Alla fine della lezione devi produrre tre artefatti:

1. un audit del repository;
2. una policy di workflow;
3. una procedura di recupero testata in sandbox.

Fase 1: audit del repository

Parti da osservazione, non da modifiche:

git status -sb
git remote -v
git branch -vv
git branch --sort=-committerdate
git log --oneline --graph --decorate --all -40
git tag --sort=-creatordate | head -20

Annota:

1. branch obsoleti;
2. branch senza upstream;
3. remote ambigui;
4. tag mancanti o incoerenti;
5. commit con messaggi poco informativi;
6. merge commit inattesi;
7. presenza o assenza di hook;
8. regole CI e branch protection.

Non cancellare nulla durante l’audit. Prima fotografa lo stato.

Fase 2: scegliere il workflow

Scegli tra trunk-based, GitHub Flow, GitFlow o una variante documentata.

Domande guida:

Rilasciamo spesso?
Supportiamo più versioni in parallelo?
Main deve essere sempre rilasciabile?
Le PR sono piccole?
La CI è affidabile?
Abbiamo feature flag?
Ci servono release branch?

Esempi:

1. SaaS con deploy frequente: trunk-based o GitHub Flow.
2. sito web con piccolo team: GitHub Flow leggero.
3. libreria versionata con supporto a versioni vecchie: release branch o GitFlow parziale.
4. app mobile con review store: release branch più utili.

La scelta deve avere motivazione, non solo nome.

Fase 3: pulire una storia locale

Crea un branch sandbox:

git switch -c capstone/git-policy

Lavora su 3-5 commit intenzionalmente sporchi: messaggio errato, file dimenticato, commit troppo grande, fixup. Poi ripulisci con:

git commit --amend
git rebase -i HEAD~5
git add -p

Risultato atteso:

commit atomici
messaggi coerenti
nessun file accidentale
storia leggibile in git log --oneline

Non riscrivere storia condivisa. L’esercizio avviene su branch locale o branch personale.

Fase 4: policy remoti, PR e tag

Scrivi una bozza di docs/git-workflow.md:

Branch principale:
Naming branch:
Quando aprire PR:
Dimensione consigliata PR:
Strategia merge:
Regole commit:
Uso force-with-lease:
Tag release:
Versioning:
Hook locali:
Controlli CI:

Se il progetto usa LiteSpeed o altri vincoli di deploy, annota anche quali modifiche richiedono attenzione extra: rewrite, asset, cache, header, compressione e build output. Git non decide questi dettagli, ma la policy deve ricordare quando coinvolgere review più rigorosa.

Fase 5: simulare recupero da disastro

Fallo solo in sandbox o su un clone temporaneo. Non usare branch reali condivisi.

Scenario:

git switch -c capstone/disaster-demo
echo "uno" > disaster.txt
git add disaster.txt
git commit -m "test: aggiungi file disastro"
echo "due" >> disaster.txt
git commit -am "test: aggiorna file disastro"

Simula errore:

git reset --hard HEAD~1

Recupera:

git reflog
git reset --hard <sha-recupero>

Poi ripeti con recupero meno invasivo:

git switch -c recovered <sha-recupero>
git cherry-pick <sha-recupero>

Devi saper spiegare la differenza: reset --hard sposta il branch e modifica working tree; cherry-pick crea un nuovo commit con lo stesso cambiamento; un branch recovered conserva un punto prima di decidere.

Fase 6: verifica finale

Esegui:

git status -sb
git log --oneline --decorate -10
git branch -vv

Se hai toccato codice reale, esegui test e build previsti dal progetto. Se hai toccato solo documentazione, verifica comunque rendering, link e frontmatter se il sito lo richiede.

Output atteso

Consegna finale:

1. Audit repo
2. Workflow scelto e motivazione
3. Policy commit e PR
4. Policy tag/versioning
5. Policy force push
6. Hook locali e controlli CI
7. Procedura recupero con reflog
8. Elenco rischi ancora aperti

Il valore del capstone non è avere una policy perfetta. È rendere esplicite le decisioni che altrimenti restano nella testa delle persone.

Errori comuni

Partire dalle pulizie prima dell’audit. Rischi di cancellare contesto utile.

Scegliere workflow per moda. Il workflow deve seguire release, team e rischio.

Provare recuperi su branch condivisi. Le simulazioni si fanno in sandbox.

Scrivere policy troppo lunghe. Se nessuno le legge, non governano il lavoro.

Dimenticare la piattaforma remota. Branch protection, PR rules e CI sono parte del workflow quanto i comandi locali.

Checklist di verifica

• ho fotografato lo stato del repository;
• ho scelto e motivato un workflow;
• ho ripulito una storia locale senza toccare storia condivisa;
• ho documentato commit, PR, tag e force push;
• ho simulato e spiegato un recupero con reflog;
• ho identificato controlli locali e controlli CI.

Collegamenti

• Modulo: Casi reali, debugging della storia, recupero - lezione 36 del corso.
• Riunisce branch, merge, rebase, remoti, workflow, tag, hook e reflog.