Sinossi
git add [-p] [-A] [-u] [--] [<pathspec>...]Descrizione
Il comando git add sposta le modifiche dalla tua working tree alla staging area (chiamata anche index). La staging area è uno snapshot di ciò che andrà nel prossimo commit. Mettendo in stage le modifiche esplicitamente, Git ti permette di creare commit che contengono esattamente il lavoro che vuoi registrare — anche se la tua working tree ha altre modifiche non correlate in corso.
git add può mettere in stage interi file, parti di file (con -p) o directory. Non committa nulla; aggiorna solo l'index. Il workflow più comune è: modifica, git status, git add, git commit. Padroneggiare git add, specialmente le sue modalità interattive, è uno dei modi migliori per rendere la storia dei commit leggibile e facile da rivedere.
Nell'uso quotidiano, git add si integra strettamente con alias della shell, plugin dell'editor e integrazione continua. Gli utenti esperti spesso aggiungono alias che combinano flag che passano sempre, o avvolgono il comando in script che applicano convenzioni del team. La formattazione dell'output può essere personalizzata tramite Git config — formati pretty, schemi di colori e comportamento del pager sono tutti regolabili. Quando qualcosa va storto, il primo passo diagnostico è di solito ri-eseguire il comando con GIT_TRACE=1 nell'ambiente, che rivela le chiamate di plumbing sottostanti. Per situazioni insolite, l'output di --help (git add --help) apre la man page completa con dettagli su ogni opzione.
Capire come git add interagisce con il resto del modello dati di Git — il database degli oggetti, l'index, i ref e la working tree — paga dividendi. Ogni comando opera su un sottoinsieme di questi pezzi, e sapere quali tocca aiuta a prevedere i risultati e recuperare dagli errori. La maggior parte dei problemi di produzione con Git deriva da una di tre cause: comportamento predefinito sorprendente, operazioni di rete parziali o riscrittura di storia già condivisa.
Opzioni comuni
| Opzione | Descrizione |
|---|---|
-A, --all | Mette in stage tutte le modifiche nella working tree, incluse cancellazioni e nuovi file. |
-u, --update | Mette in stage solo modifiche e cancellazioni di file tracciati — ignora i nuovi file. |
-p, --patch | Sceglie interattivamente gli hunk di modifiche da mettere in stage. |
-n, --dry-run | Mostra cosa verrebbe messo in stage senza farlo. |
-f, --force | Aggiunge file anche se corrispondono a .gitignore. |
-i, --interactive | Apre un'interfaccia a menu per lo staging. |
--intent-to-add / -N | Registra l'intento di aggiungere un file così che il suo diff appaia. |
Esempi
git add README.md src/main.c
# Mette in stage due file specifici
git add -A
# Mette in stage tutto: file nuovi, modificati e cancellati
git add -p
# Rivede e mette in stage gli hunk uno a uno interattivamente
git add 'src/**/*.js'
# Mette in stage tutti i file JavaScript sotto src usando un pathspecErrori comuni
Eseguire git add . alla cieca spesso mette in stage file non intenzionali — file di log, artefatti di build, chiavi segrete. Usa prima git status e considera -p per modifiche sensibili. Un'altra confusione comune: git add -u non prenderà i nuovi file, mentre git add . sì. Dopo aver messo in stage, se modifichi di nuovo un file, quelle modifiche successive non sono in stage finché non ri-esegui git add.
Comandi correlati
git commit, git status, git restore, git reset