Il tuo primo progetto: scaffolding, Dev Server, Git e GitHub

Panoramica

E la lezione in cui l'astratto diventa concreto. Fai lo scaffolding di un vero progetto, lo fai girare nel tuo browser e lo metti sotto version control in un repo GitHub privato. Alla fine, hai un'app che gira localmente e una cronologia sicura e salvata del tuo lavoro - la fondazione su cui ogni progetto successivo si appoggia.

Cosa imparerai

Fai lo scaffolding di un progetto con il tuo agente, lanci un Dev Server e lo vedi sotto localhost, capisci cosa fanno davvero Git e i commit, e pubblichi il tuo codice in un repository GitHub privato con i segreti esclusi in sicurezza. Sono i gesti quotidiani della costruzione, quindi facciamone subito memoria muscolare.

Prerequisiti

Un setup d'agente funzionante, Node.js e un account GitHub (gratuito). Le pagine dei fondamenti su Git, GitHub, il terminale e su cos'e un Dev Server aiutano se un termine ti e nuovo qui - dagli un'occhiata poi torna. Non hai bisogno di conoscere i comandi Git a memoria; l'agente ne esegue la maggior parte, ma devi capire cosa fanno.

Il problema

I principianti restano bloccati tra "ho un'idea" e "gira sul mio schermo". Non sanno come avviare un progetto, hanno paura del terminale e sono confusi da Git. Il risultato e una cartella piena di file senza cronologia e senza backup, dove una modifica sbagliata perde ore di lavoro. Questa lezione colma questo divario per sempre.

Passo passo: scaffolding e far girare

Invece di imparare un framework a memoria, chiedi al tuo agente di fare lo scaffolding di uno starter moderno e di spiegare ogni passo. Una scelta comune e accessibile ai principianti e un progetto basato su Vite, ma la stack esatta conta meno della comprensione del flusso: creare il progetto, installare le dipendenze, lanciare il Dev Server, aprire il browser.

# Fare lo scaffolding di un nuovo progetto Vite (il tuo agente puo eseguirlo per te)
npm create vite@latest my-first-app

# Entrarci e installare le dipendenze necessarie
cd my-first-app
npm install

# Lanciare il Dev Server locale
npm run dev

Il Dev Server mostra un indirizzo locale, spesso del tipo http://localhost:5173. Aprilo nel tuo browser e vedrai la tua app girare sulla tua stessa macchina. "localhost" vuol dire semplicemente "questo computer" - niente e ancora su Internet, il che e esattamente cio che serve mentre costruisci. Modifica un file, salva, e il browser si aggiorna subito. Questo ciclo dal vivo fa sembrare veloce la costruzione web.

Cosa fa realmente Git

Git e version control: prende istantanee del tuo progetto chiamate commit, perche tu possa sempre tornare indietro. Vedilo come una cronologia di annullamento illimitata con delle etichette. Ogni commit registra cosa e cambiato e perche, il che significa che una modifica sbagliata non e mai una catastrofe - torni semplicemente all'ultimo buon commit. Questa sola abitudine toglie la paura che impedisce ai principianti di sperimentare, perche niente di cio che fai e definitivo finche non lo decidi tu.

# Cominciare a tracciare questo progetto con Git
git init

# Mettere tutti i file attuali in attesa per la prima istantanea
git add .

# Registrare l'istantanea con un messaggio descrittivo
git commit -m "Initial project scaffold"

Tenere i segreti fuori prima di pubblicare

Prima di pubblicare mai su GitHub, assicurati che i segreti non possano scappare. Un file .gitignore elenca le cose che Git deve ignorare. Il tuo file .env - dove vivono le chiavi API - e la cartella node_modules ci stanno entrambi. Fallo bene una volta e non pubblicherai mai una chiave per sbaglio. Il tuo agente puo creare questo file, ma devi saperne riconoscere uno corretto.

# .gitignore - dice a Git cosa non deve mai tracciare
node_modules
.env
.env.local
dist

La regola e assoluta: i segreti vanno in .env, .env va in .gitignore, e l'agente non scrive mai una chiave in codice committato. Se non ricordi nient'altro della sicurezza di questo corso, ricorda questo.

Passo passo: pubblicare in un repo GitHub privato

GitHub archivia il tuo repository nel cloud: un backup, una cronologia, e piu avanti cio a cui il tuo deployment si connette. Crea il repository in privato perche il tuo codice business ti appartenga. L'agente puo fare l'essenziale, ma ecco cosa succede sotto il cofano.

# Creare un repo PRIVATO e pubblicare, con la GitHub CLI
gh repo create my-first-app --private --source=. --push

# O, se hai creato il repo prima su github.com:
git remote add origin https://github.com/yourname/my-first-app.git
git push -u origin main

Privato e il default che vuoi per tutto cio che e commerciale. I repo pubblici sono ottimi per l'open source, ma la tua IP business dovrebbe partire in privato e passare in pubblico solo deliberatamente, dopo un security review - un argomento che il Corso 5 tratta in dettaglio.

Errori frequenti

I dolorosi: committare un file .env con una chiave API attiva (ormai per sempre nella tua cronologia, anche se lo cancelli piu tardi); non lanciare mai git commit, cosicche non c'e cronologia a cui tornare; creare un repo pubblico per codice business privato; e farsi prendere dal panico al terminale invece di lasciare l'agente eseguire i comandi mentre leggi cosa fanno. Vai lentamente, leggi ogni comando e committa presto e spesso.

ROI business

Il version control e un'assicurazione economica dall'enorme beneficio. Un solo errore riparabile - annullare una modifica rovinosa in pochi secondi invece di ricostruirla per ore - ripaga l'abitudine molte volte. Un repo privato protegge l'IP su cui poggia il tuo business. E un'app che gira localmente vuol dire che puoi iterare veloce, il che e tutto il senso di costruire con gli agenti.

Checklist

Sei pronto a pubblicare non appena ognuno di questi punti e vero. Non saltare i punti di sicurezza dei segreti - contano piu di quanto sembri.

• Il tuo progetto gira localmente e puoi aprirlo sotto localhost.
• Il progetto e un repo Git con almeno un commit.
• .env e in .gitignore e non contiene segreti in nessun file committato.
• Il codice e pubblicato in un repository GitHub PRIVATO.

Risorse

Le pagine dei fondamenti su Git, GitHub e il Dev Server sono il tuo riferimento se un passo era traballante. La checklist di setup Claude Code nella libreria di risorse annota queste protezioni in una lista riutilizzabile. Resta un passo: portare questo dalla tua macchina a Internet.

La tua missione

Fai lo scaffolding di un piccolo progetto, fallo girare localmente, fai almeno due commit cambiando qualcosa, e pubblicalo in un repo GitHub privato con un .gitignore corretto. Conferma su github.com che il tuo .env non e reperibile da nessuna parte. Ora hai un vero progetto, sotto version control e salvato.

Prossima lezione

La tua app gira sulla tua macchina. L'ultima lezione di questo corso la mette su Internet: deployment su Vercel, connessione di un vero dominio e gestione del DNS e di Cloudflare, perche chiunque nel mondo possa visitare il tuo sito.