Directory di lavoro vs area di staging vs repository locale: capire le tre zone locali di Git

By Mirko Peters · 2026-08-12

Padroneggia le tre zone locali di Git: scopri come directory di lavoro, area di staging e repository locale collaborano per darti un controllo preciso sulla cronologia del tuo progetto.

Automatically translated with AI from the original post. Read the English original

Orientarsi tra le tre aree locali di Git (la directory di lavoro, l'area di staging e il repository locale) è essenziale per passare dalla copia caotica dei file a un controllo di versione consapevole. Questa guida spiega come funziona ciascuna zona, con un paragone con un ufficio fisico, per darti un controllo preciso sulla cronologia del tuo progetto.

Punti chiave

• La directory di lavoro è la cartella attiva del progetto, un po' come una scrivania disordinata su cui modifichi i file liberamente.
• L'area di staging funziona come un vassoio di revisione: contiene solo le modifiche che selezioni con git add per il prossimo checkpoint.
• Il repository locale è come lo schedario: registra in modo permanente le modifiche in staging sotto forma di una cronologia di commit strutturata.
• I comandi git status e git diff offrono controlli di sicurezza che ti permettono di verificare cosa sta succedendo nelle tue aree locali prima di registrare la cronologia.
• Capire queste tre zone previene i commit accidentali e ti aiuta a mantenere la cronologia del progetto pulita e logica.

La directory di lavoro: la tua scrivania attiva

Quando apri una cartella di progetto sul computer e inizi a modificare i file, stai operando direttamente nella prima zona locale di Git: la directory di lavoro. Immagina questa cartella come la tua scrivania in ufficio. Contiene ogni file che apri, crei, modifichi o elimini, inclusi codice del sito web, documentazione, file di configurazione e immagini.

Come una scrivania vera, la directory di lavoro può diventare disordinata mentre sperimenti. Potresti iniziare a riscrivere un pulsante di accesso, notare un errore di battitura in un file readme e creare uno script sperimentale per testare un nuovo layout. Git non trasforma automaticamente ogni singola modifica in cronologia permanente solo perché è avvenuta in questa cartella. Sei libero di provare idee, sbagliare e lasciare lavori incompiuti senza alterare in modo permanente la storia del progetto.

Per vedere cosa è cambiato nella directory di lavoro dall'ultimo checkpoint registrato, usi il comando git status. In parole semplici, chiedere a Git lo stato equivale a fare l'inventario di tutto ciò che si trova sulla scrivania. Git individua i file modificati, nuovi ed eliminati, mostrandoti esattamente cosa è cambiato dall'ultimo commit.

L'area di staging: il vassoio di revisione

L'area di staging è forse il concetto più frainteso da chi si avvicina al controllo di versione per la prima volta, soprattutto perché il nome sembra suggerire un misterioso magazzino tecnico. Immagina invece l'area di staging come un vassoio di revisione posato accanto alla scrivania. Vi inserisci solo le modifiche destinate al prossimo checkpoint.

Supponi di passare la mattinata a correggere un link critico per il reset della password e, nello stesso tempo, di iniziare una riprogettazione sperimentale della schermata di benvenuto. La correzione della password va sicuramente registrata, ma la riprogettazione è incompleta e contiene bug. Non vuoi che entrambe le modifiche finiscano nello stesso commit.

Eseguendo git add seguito dal file di reimpostazione della password, inserisci quella specifica modifica completata nell'area di staging. Nonostante il nome, git add non salva in modo permanente il tuo lavoro né invia nulla a un server online. Prepara semplicemente una versione pulita e selezionata di quel file per il tuo prossimo checkpoint. Questa breve pausa ti dà un controllo enorme. Puoi rivedere le modifiche in staging, rimuovere gli elementi aggiunti prematuramente oppure includere altri file che appartengono esattamente alla stessa unità di lavoro logica.

Il repository locale: lo schedario

Una volta che il vassoio di revisione contiene l'insieme preciso di modifiche che vuoi conservare, queste passano nella terza zona di Git: il repository locale. Se la directory di lavoro è la tua scrivania e l'area di staging è il tuo vassoio di revisione, il repository locale è il tuo schedario sicuro.

Il repository locale memorizza tutti i commit e la cronologia del progetto direttamente sul tuo computer, all'interno di cartelle di sistema nascoste. Quando esegui git commit -m "Fix password reset link", Git prende le modifiche preparate nell'area di staging e le blocca in un checkpoint permanente e denominato.

Questa architettura local-first significa che puoi costruire una cronologia del progetto completa e tracciabile senza una connessione internet o un servizio di hosting online. Tutto avviene in modo sicuro sul tuo hardware. Il flusso di lavoro quotidiano diventa un ritmo affidabile: modifichi i file nella directory di lavoro, verifichi la situazione con git status, selezioni le modifiche mirate con git add e registri le tue scelte con git commit.

Conclusione

Padroneggiare la distinzione tra directory di lavoro, area di staging e repository locale cambia il modo in cui affronti i progetti di sviluppo. Trattando la cartella come uno spazio di lavoro, l'area di staging come un vassoio di revisione e il repository locale come uno schedario permanente, ottieni il controllo totale sulla cronologia del progetto.

Per approfondire i fondamenti del controllo di versione, ascolta l'episodio completo del podcast M365 FM, in cui Mirko Peters spiega Git in parole semplici e mostra come questi meccanismi locali si inseriscono nei flussi di lavoro di team più ampi.

Domande frequenti

Qual è la differenza tra directory di lavoro e area di staging?

La directory di lavoro è la cartella attiva del progetto in cui modifichi, crei ed elimini liberamente i file. L'area di staging è un vassoio di revisione selettivo in cui inserisci solo le modifiche specifiche che intendi includere nel tuo prossimo commit.

Il comando git add salva in modo permanente i miei file?

No. Il comando git add prepara i file spostandoli nell'area di staging, ma non li registra in modo permanente nella cronologia del progetto né li invia online. La registrazione permanente avviene solo quando esegui git commit.

Posso usare Git senza un servizio di hosting online?

Sì. Git è progettato per funzionare interamente in locale sul tuo computer. Puoi creare un repository locale, effettuare commit, gestire i branch e consultare la cronologia senza mai collegarti a GitHub o a internet.

Cosa devo fare se aggiungo per errore un file allo staging?

Se aggiungi un file troppo presto all'area di staging, Git mette a disposizione comandi di rimozione dallo staging (come git reset) che rimuovono in sicurezza il file dall'area di staging e lo riportano nella directory di lavoro senza perdere le tue ultime modifiche.