Introduzione

Nel linguaggio comune si "salva" un documento, ma in Git l'azione equivalente si chiama commit. Un commit registra uno snapshot permanente dei tuoi file in staging e delle loro modifiche nella cronologia del repository. A differenza di premere Salva in un editor, un commit non sovrascrive la versione precedente — aggiunge una nuova voce a una timeline che puoi rivisitare, confrontare o ripristinare in qualsiasi momento.

Questa pagina è una mappa dei comandi che usi per salvare le modifiche localmente e prepararle per la condivisione. Ogni sezione rimanda a un capitolo dedicato con opzioni ed esempi completi.

Le tre aree attraverso cui passano le modifiche

Per capire il salvataggio in Git, è utile sapere che un file può trovarsi in tre posti contemporaneamente:

• Working directory — i file che modifichi su disco.
• Staging area (chiamata anche index) — una zona di attesa in cui assembli esattamente ciò che il prossimo commit conterrà.
• Repository — la cronologia dei commit, memorizzata nella cartella nascosta .git.

Salvare le modifiche significa spostarle dalla working directory, attraverso la staging area, e nel repository:

edit files        # changes live in the working directory
git add <file>    # move them into the staging area
git commit        # record them permanently in the repository

Il flusso in due fasi add poi commit è intenzionale: ti consente di fare il commit solo di una parte del tuo lavoro e lasciare il resto per dopo, producendo commit mirati e significativi.

git add

Il comando git add sposta le modifiche dalla working directory alla staging area. Indica a Git quali aggiornamenti includere nel prossimo commit. Da solo git add non registra nulla di permanente — devi seguirlo con git commit.

git add index.html      # stage a single file
git add src/            # stage everything under a directory
git add .               # stage all changes in the current directory tree

Esegui git status in qualsiasi momento per vedere quali file sono in staging, modificati o non tracciati.

git commit

Il comando git commit registra tutte le modifiche attualmente in staging come un nuovo snapshot nel repository. Ogni commit è un punto permanente nella cronologia a cui puoi tornare. Poiché vengono acquisite solo le modifiche in staging, git add deve essere eseguito prima.

git commit -m "Add contact form validation"

Usa un messaggio breve e descrittivo al modo imperativo ("Add", "Fix", "Update"). Se ometti -m, Git apre l'editor configurato così puoi scrivere un messaggio più lungo.

git diff

Il comando git diff confronta diversi stati del tuo progetto in modo da poter esaminare esattamente ciò che stai per salvare. Per impostazione predefinita git diff mostra le modifiche non in staging — la differenza tra la working directory e la staging area. Aggiungi --staged per vedere cosa è già in staging e pronto per il commit.

git diff             # working directory vs. staging area (not yet staged)
git diff --staged    # staging area vs. last commit (about to be committed)

Esaminare un diff prima del commit è il modo migliore per evitare di salvare codice di debug o modifiche accidentali.

git stash

Il comando git stash ripone temporaneamente le modifiche non committate in modo che la tua working directory diventi pulita — utile quando devi cambiare attività o fare il pull degli aggiornamenti senza fare il commit di lavoro a metà. Le modifiche vengono salvate in uno stack che puoi riapplicare in seguito.

git stash        # set aside current changes and revert to a clean tree
git stash pop    # re-apply the most recent stash and remove it from the stack

.gitignore

Alcuni file non dovrebbero mai essere committati — output di build, dipendenze, segreti o metadati del sistema operativo. Git legge un file chiamato .gitignore per decidere quali percorsi saltare. Non esiste un comando git ignore; crei e fai il commit di questo file tu stesso, elencando i pattern che Git deve escludere dal tracciamento:

# Dependencies
node_modules/
# OS files
.DS_Store
Thumbs.db
# Secrets
.env

Nota che .gitignore influisce solo sui file che Git non sta già tracciando. Per smettere di tracciare un file che era già stato committato prima di essere ignorato, usa git rm --cached.

Flusso di lavoro tipico

Una sequenza standard per salvare e condividere le modifiche si presenta così:

git status                          # see what changed
git add .                           # stage the changes
git diff --staged                   # review what is about to be committed
git commit -m "Implement feature"   # save a permanent snapshot
git push origin main                # upload commits to the remote

I primi quattro passaggi salvano il lavoro localmente; git push è ciò che lo condivide con un server remoto come GitHub.

Annullare prima di salvare

Se metti qualcosa in staging per errore, puoi rimuoverlo dalla staging area senza perdere le modifiche:

git restore --staged <file>    # unstage, keep the changes in the working directory
git restore <file>             # discard working-directory changes (cannot be undone)

Per altri modi di annullare le modifiche dopo il commit, vedi git reset.

Esercitazione