Guida rapida Git — Comandi per attività

Comandi Git organizzati per ciò che vuoi fare: annullare l'ultimo commit, rinominare un branch, eliminare un branch remoto. I moderni switch/restore con gli equivalenti classici e badge di pericolo.

Ultima verifica: 2026-10-18 su il riferimento di git-scm.com per Git 2.56 e il manuale di GitHub CLI. Fonti: Git reference (git-scm.com/docs), git restore, git switch, git reset, git config, GitHub CLI manual.

Cerca per attività o comando

97 comandi

Più cercati:

Riscrive la cronologia sicuro solo su commit che nessun altro ha scaricato · ⚠ Elimina lavoro può eliminare modifiche per sempre. I pulsanti Copia escludono i commenti #.

Configurazione (una volta per computer)

Con --global le impostazioni vanno in ~/.gitconfig. Da Git 2.46 la forma documentata è git config set / get / list; la forma classica funziona ancora.

Imposta nome ed email#Git 2.46+

git config set --global user.name "Ana Lee"
git config set --global user.email "ana@example.com"

Classico: git config --global user.name "Ana Lee"

Registrati in ogni commit che fai. Usa l'email nota al tuo host Git, così i commit vengono collegati al tuo account.

Fai partire i nuovi repository su main#

git config set --global init.defaultBranch main

Classico: git config --global init.defaultBranch main

Senza questa impostazione, git init chiama ancora master il primo branch (e mostra un suggerimento).

Scegli l'editor per i messaggi di commit#

git config set --global core.editor "code --wait"

Classico: git config --global core.editor "code --wait"

Funziona qualsiasi comando che resti in attesa finché il file non viene chiuso: "nano", "vim", "subl -n -w".

Gestisci i fine riga di Windows / macOS#

git config set --global core.autocrlf true  # Windows
git config set --global core.autocrlf input  # macOS, Linux

Classico: git config --global core.autocrlf true

Esegue il commit con LF e il checkout con CRLF su Windows. Per un intero team, un file .gitattributes con "* text=auto" è più affidabile delle impostazioni personali.

Controlla quale versione di Git hai#

git --version

git switch e git restore richiedono la 2.23+, i sottocomandi di git config la 2.46+.

Avviare un repository

Trasforma una cartella in un repository#

git init
git init -b main  # name the first branch

Crea una directory .git. Aggiungi un .gitignore prima del primo commit, così file di build e segreti non entrano mai.

Copia un repository esistente#

git clone https://github.com/owner/repo.git
git clone git@github.com:owner/repo.git my-folder

Scarica tutta la cronologia e imposta il remote "origin". La seconda forma usa SSH e un nome di cartella personalizzato.

Clona solo l'ultima versione (più veloce)#

git clone --depth 1 https://github.com/owner/repo.git

Salta la cronologia; utile per la CI e i repository grandi. git fetch --unshallow scarica il resto in seguito.

Pubblica un nuovo repository locale#

git remote add origin git@github.com:owner/repo.git
git push -u origin main

Crea prima il repository vuoto sull'host (oppure usa gh repo create, più sotto). -u memorizza origin/main come upstream.

Stage e commit

Vedi cosa è cambiato#

git status
git status -s  # short form

Elenca i file in stage, non in stage e non tracciati, e suggerisce il comando successivo.

Metti i file in stage per il prossimo commit#

git add file.txt
git add .  # everything in this folder and below

git add -A mette in stage anche le eliminazioni in tutto il repository.

Metti in stage solo una parte di un file#

git add -p file.txt

Scorre ogni modifica ("hunk"): y per metterla in stage, n per saltarla, s per dividerla, e per modificarla.

Esegui il commit delle modifiche in stage#

git commit -m "Add login form"
git commit -am "Fix typo"  # stage tracked files and commit

-a include i file tracciati modificati ed eliminati, mai quelli nuovi.

Rinomina o elimina un file tracciato#

git mv old.txt new.txt
git rm file.txt

Entrambi mettono la modifica in stage per te. Git rileva le rinomine dal contenuto, quindi funziona anche un semplice mv più git add.

Smetti di tracciare un file ma tienilo su disco#

git rm --cached .env
echo ".env" >> .gitignore

Lo rimuove dal repository a partire dal prossimo commit. Resta nei commit precedenti: se conteneva un segreto, cambia il segreto.

Branch

Elenca i branch#

git branch
git branch -a  # include remote branches
git branch -vv  # show upstream and ahead/behind

Il branch corrente è segnato con *.

Crea un branch e passa a quel branch#Git 2.23+

git switch -c feature/login

Classico: git checkout -b feature/login

Parte dal commit corrente; aggiungi un punto di partenza per diramarti da altrove: git switch -c hotfix origin/main.

Passa a un altro branch#Git 2.23+

git switch main
git switch -  # back to the previous branch

Classico: git checkout main

Se esiste solo origin/feature, git switch feature crea automaticamente un branch locale di tracking.

Rinomina un branch#

git branch -m new-name  # current branch
git branch -m old-name new-name

Rinomina solo in locale. Per rinominarlo anche sul remote, vedi la voce successiva.

Rinomina un branch sul remote#

git branch -m old-name new-name
git push -u origin new-name
git push origin --delete old-name

Non esiste una rinomina remota: fai il push del nuovo nome ed elimina quello vecchio. Le pull request aperte sul vecchio nome potrebbero chiudersi; il pulsante di rinomina nell'interfaccia web di GitHub le reindirizza.

Elimina un branch locale#⚠ Elimina lavoro

git branch -d feature/login
git branch -D feature/login  # even if unmerged

-d si rifiuta se il branch ha commit non uniti nel suo upstream o in HEAD; -D elimina comunque.

Recupero: I commit non uniti sono ancora nel reflog: git reflog, trova la punta, poi git branch feature/login <sha>.

Elimina un branch remoto#⚠ Elimina lavoro

git push origin --delete feature/login

Classico: git push origin :feature/login

I colleghi continuano a vederlo finché non eseguono git fetch --prune.

Recupero: Chiunque abbia il branch in locale (o tu, tramite git reflog) può ripubblicarlo con un push.

Imposta o cambia il branch upstream#

git branch -u origin/main
git push -u origin HEAD  # push current branch and track it

Classico: git branch --set-upstream-to=origin/main

L'upstream è ciò che usano git pull e git push senza argomenti.

Guarda un vecchio commit (HEAD scollegato)#Git 2.23+

git switch --detach a1b2c3d
git switch -c rescue  # keep work made there

Classico: git checkout a1b2c3d

I commit fatti con HEAD scollegato non appartengono a nessun branch; creane uno prima di spostarti, altrimenti saranno raggiungibili solo tramite il reflog.

Merge, rebase e cherry-pick

Unisci un branch in quello corrente#

git switch main
git merge feature/login
git merge --no-ff feature/login  # always create a merge commit

Usa il fast-forward quando possibile; --no-ff mantiene il branch visibile nella cronologia.

Comprimi un branch in un solo commit (squash)#

git merge --squash feature/login
git commit -m "Add login"

Mette in stage le modifiche combinate senza registrare un merge; in seguito il branch non risulta unito.

Risolvi un conflitto di merge#

git status  # list conflicted files
# edit the files, remove <<<<<<< ======= >>>>>>> markers
git add file.txt
git commit  # or: git rebase --continue

Prendi un lato per intero con git restore --ours file.txt o --theirs. Durante un rebase "ours" è il branch su cui stai facendo il rebase, l'opposto di un merge.

Interrompi un merge in corso#⚠ Elimina lavoro

git merge --abort

Torna allo stato precedente all'inizio del merge.

Recupero: Le risoluzioni dei conflitti che hai fatto vanno perse. Se avevi modifiche non committate quando è iniziato il merge, --abort potrebbe non riuscire a ripristinarle: fai commit o stash prima del merge.

Fai il rebase di un branch su main#Riscrive la cronologia

git switch feature/login
git rebase main

Riapplica i tuoi commit sopra main per una cronologia lineare. Risolvi i conflitti, git add, poi git rebase --continue; --abort rinuncia.

Recupero: Subito dopo: git reset --hard ORIG_HEAD. Più tardi: trova la vecchia punta in git reflog.

Unisci, riordina o riformula i commit recenti#Riscrive la cronologia

git rebase -i HEAD~3

Apre un elenco: cambia pick in squash/fixup per combinare, reword per modificare un messaggio, drop per eliminare, oppure riordina le righe.

Recupero: git reflog mostra il commit precedente al rebase; git reset --hard <sha> lo ripristina.

Correggi un commit più vecchio#Riscrive la cronologia

git commit --fixup=a1b2c3d
git rebase -i --autosquash a1b2c3d~1

Il commit di fixup viene incorporato automaticamente in a1b2c3d quando fai il rebase.

Recupero: Come per il rebase interattivo: git reflog.

Fai il pull senza commit di merge#

git pull --rebase
git config set --global pull.rebase true  # make it the default

Esegue il rebase dei tuoi commit locali sopra quanto scaricato.

Copia un commit da un altro branch#

git cherry-pick a1b2c3d
git cherry-pick -x a1b2c3d  # note the source in the message

Crea un nuovo commit con le stesse modifiche. Un intervallo: git cherry-pick A..B (esclude A).

Remote: fetch, pull, push

Mostra e modifica i remote#

git remote -v
git remote set-url origin git@github.com:owner/repo.git

set-url sposta un clone da HTTPS a SSH (o verso un repository rinominato).

Scarica le modifiche senza unirle#

git fetch
git fetch --prune  # also drop deleted remote branches

Aggiorna solo origin/*; i tuoi branch restano intatti.

Aggiorna il branch corrente#

git pull

git fetch più merge (o rebase, se pull.rebase è impostato).

Invia i commit (push)#

git push
git push -u origin HEAD  # first push of a new branch
git config set --global push.autoSetupRemote true

Con push.autoSetupRemote (Git 2.37+), un semplice git push su un nuovo branch imposta da solo l'upstream.

Force push sicuro dopo aver riscritto la cronologia#Riscrive la cronologia

git push --force-with-lease

A differenza di --force, si rifiuta se il remote ha commit che non hai scaricato. Aggiungi --force-if-includes (Git 2.30+) per maggiore sicurezza con i fetch in background.

Recupero: I commit remoti sovrascritti sopravvivono nel reflog di chi li aveva, e GitHub li mantiene raggiungibili tramite SHA per un certo tempo.

Aggiorna un fork dal repository originale#

git remote add upstream https://github.com/original/repo.git
git fetch upstream
git switch main
git merge upstream/main

Oppure con GitHub CLI: gh repo sync.

Annullare

Scegli in base a dove si trova l'errore: nella directory di lavoro, nell'area di staging, in un commit locale o in un commit già inviato. Tutto ciò che è stato committato almeno una volta di solito si ritrova con git reflog; le modifiche non committate che scarti no.

Annulla l'ultimo commit (mantenendo le modifiche)#Riscrive la cronologia

git reset --soft HEAD~1

Il commit sparisce; le sue modifiche restano in stage, pronte per un nuovo commit. Usa git reset HEAD~1 (senza --soft) per tenerle invece fuori dallo stage.

Recupero: git reset ORIG_HEAD riporta indietro il commit. Se era già stato inviato, usa invece git revert.

Butta via l'ultimo commit e le sue modifiche#⚠ Elimina lavoro

git reset --hard HEAD~1

Sposta il branch indietro di un commit e riporta ogni file tracciato a quello stato.

Recupero: Il commit è in git reflog (le voci non raggiungibili scadono dopo 30 giorni per impostazione predefinita): git reset --hard HEAD@{1}. Le modifiche non committate nei file tracciati sono perse per sempre.

Annulla un commit già inviato#

git revert a1b2c3d
git revert HEAD  # the latest commit

Aggiunge un nuovo commit che inverte quello vecchio, così la cronologia degli altri non cambia. È l'annullamento sicuro per i branch condivisi.

Annulla (revert) un commit di merge#

git revert -m 1 <merge-sha>

-m 1 mantiene il primo genitore (di solito main). Per unire di nuovo il branch in seguito serve prima un revert di questo revert.

Cambia il messaggio dell'ultimo commit#Riscrive la cronologia

git commit --amend -m "Better message"

Sostituisce l'ultimo commit con uno nuovo. Va bene prima del push; dopo il push richiede --force-with-lease.

Recupero: git reset --soft HEAD@{1} torna al commit precedente all'amend.

Aggiungi un file dimenticato all'ultimo commit#Riscrive la cronologia

git add forgotten.txt
git commit --amend --no-edit

Mantiene il messaggio, aggiunge il file.

Recupero: git reset --soft HEAD@{1}.

Togli un file dallo stage (annulla git add)#Git 2.23+

git restore --staged file.txt
git restore --staged .  # everything

Classico: git reset HEAD file.txt

Le modifiche restano nella directory di lavoro; viene annullato solo lo staging.

Scarta le modifiche a un file#⚠ Elimina lavoroGit 2.23+

git restore file.txt

Classico: git checkout -- file.txt

Riporta il file alla versione in stage (o all'ultimo commit se nulla è in stage).

Recupero: Non recuperabile da Git: le modifiche non sono mai state committate. La cronologia locale del tuo editor potrebbe ancora averle.

Scarta tutte le modifiche locali#⚠ Elimina lavoroGit 2.23+

git restore --staged --worktree .
git clean -fd  # also delete untracked files

Classico: git reset --hard git clean -fd

Torna all'ultimo commit. Esegui prima git clean -n per vedere cosa verrebbe eliminato.

Recupero: Non recuperabile: le modifiche non committate e i file non tracciati vengono eliminati. git stash -u è l'alternativa reversibile.

Ripristina un file eliminato#Git 2.23+

git restore file.txt  # deletion not committed
git restore --source=a1b2c3d~1 file.txt  # deleted in commit a1b2c3d

Classico: git checkout a1b2c3d~1 -- file.txt

Trova il commit che l'ha eliminato con git log --diff-filter=D -- file.txt.

Recupera un file com'era in un altro commit o branch#⚠ Elimina lavoroGit 2.23+

git restore --source=main -- config.yml

Classico: git checkout main -- config.yml

Sovrascrive solo la copia di lavoro; aggiungi --staged --worktree per metterlo anche in stage. Solo per guardarlo: git show main:config.yml.

Recupero: Le modifiche non committate a quel file vengono sovrascritte.

Trova commit persi o un branch eliminato#

git reflog
git branch rescued a1b2c3d

Il reflog registra ogni posizione in cui è stato HEAD. Trova lo SHA di prima dell'errore e crea un branch lì.

Annulla un merge non ancora inviato#⚠ Elimina lavoro

git reset --hard ORIG_HEAD

ORIG_HEAD viene impostato da merge, rebase e reset sulla posizione precedente. Viene sovrascritto dal successivo comando di questo tipo.

Recupero: git reflog elenca ancora il commit di merge.

Annulla un rebase#⚠ Elimina lavoro

git reflog  # find "rebase (start)"; the entry below it is the old tip
git reset --hard HEAD@{5}

Subito dopo il rebase, git reset --hard ORIG_HEAD fa la stessa cosa.

Recupero: --hard scarta le modifiche non committate; mettile prima in stash.

Annulla un git reset#⚠ Elimina lavoro

git reset --hard HEAD@{1}

HEAD@{1} è dove si trovava HEAD prima dell'ultimo spostamento. Funziona solo per il lavoro committato.

Rimuovi dalla cronologia un segreto o un file enorme committato#Riscrive la cronologia

git filter-repo --invert-paths --path secrets.env

git filter-repo è uno strumento separato (pip install git-filter-repo), consigliato dalla documentazione di git-filter-branch. Dopo, ogni clone va rifatto da zero. Cambia comunque il segreto: era pubblico dal momento del push.

Recupero: filter-repo lavora su un clone nuovo; conserva il vecchio clone finché non sei sicuro.

Stash

Metti da parte il lavoro temporaneamente#

git stash
git stash push -m "half-done login"
git stash -u  # include untracked files

Salva le modifiche tracciate e ripulisce la directory di lavoro, così puoi cambiare branch.

Recupera il lavoro messo in stash#

git stash pop  # apply and drop
git stash apply stash@{1}  # apply, keep the stash

Possono esserci conflitti; con pop, lo stash viene conservato se l'applicazione non riesce.

Elenca e ispeziona gli stash#

git stash list
git stash show -p stash@{0}

Dal più recente; stash@{0} è l'ultimo.

Metti in stash solo alcuni file#

git stash push -- src/login.ts
git stash push --staged  # only what is staged (2.35+)

Gli stash limitati a dei percorsi lasciano tutto il resto al suo posto.

Trasforma uno stash in un branch#

git stash branch feature/login stash@{0}

Crea il branch sul commit in cui hai fatto lo stash, applica lo stash e lo elimina; evita conflitti.

Elimina gli stash#⚠ Elimina lavoro

git stash drop stash@{0}
git stash clear

clear rimuove tutti gli stash.

Recupero: Uno stash eliminato è un commit non raggiungibile fino alla garbage collection: git fsck --unreachable | grep commit, poi git stash apply <sha>.

Cronologia e diff

Mostra la cronologia come grafo#

git log --oneline --graph --all

Una riga per commit con la struttura dei branch. Su versioni di Git molto vecchie aggiungi --decorate per vedere i nomi dei branch.

Cronologia di un singolo file#

git log --follow -p -- path/file.txt

--follow prosegue attraverso le rinomine; -p mostra ogni modifica.

Trova il commit che ha aggiunto o rimosso un testo#

git log -S "functionName" --oneline
git log -G "regex" --oneline

-S conta le occorrenze che cambiano; -G confronta ogni riga modificata con una regex.

Commit per autore o data#

git log --author="Ana" --since="2 weeks ago" --oneline

Anche --until, --grep="fix" per i messaggi e main..feature per i commit presenti su feature ma non su main.

Mostra un commit o una vecchia versione di un file#

git show a1b2c3d
git show a1b2c3d:path/file.txt

La seconda forma stampa il file com'era in quel commit senza toccare la tua copia.

Vedi le modifiche non ancora committate#

git diff  # unstaged
git diff --staged  # staged, i.e. what will be committed

--stat riassume per file; --word-diff è migliore per i testi in prosa.

Confronta due branch#

git diff main...feature  # changes on feature since it branched
git diff main feature  # the two tips directly

Tre punti confrontano con la merge base, cioè ciò che mostra una pull request.

Chi ha modificato ogni riga#

git blame -L 10,20 path/file.txt

Aggiungi -w per ignorare gli spazi e -C per seguire le righe spostate da altri file.

Trova il commit che ha introdotto un bug#

git bisect start
git bisect bad  # current commit is broken
git bisect good v1.4.0  # this one worked
# test, then mark each step good or bad
git bisect reset

Ricerca binaria: circa log2(n) passaggi. git bisect run ./test.sh la automatizza.

Cerca nei file tracciati#

git grep -n "TODO"

Più veloce di grep sui repository grandi e salta i file ignorati. Aggiungi un commit per cercare in una vecchia versione.

Tag e release

Tagga una release#

git tag -a v1.2.0 -m "Release 1.2.0"
git tag -a v1.1.1 a1b2c3d -m "Hotfix"  # tag an older commit

I tag annotati (-a) memorizzano autore, data e messaggio; preferiscili per le release. git tag v1.2.0 da solo crea un tag leggero.

Invia i tag#

git push origin v1.2.0
git push --follow-tags  # annotated tags reachable from pushed commits

Per impostazione predefinita git push non invia i tag. git push --tags invia tutti i tag, compresi quelli locali dimenticati.

Elimina un tag in locale e sul remote#⚠ Elimina lavoro

git tag -d v1.2.0
git push origin --delete v1.2.0

Evita di riutilizzare il nome di un tag di release eliminato: gli altri cloni conservano il vecchio tag.

Recupero: Il commit taggato non viene toccato; ricrea il tag su di esso.

Elenca i tag e descrivi la versione corrente#

git tag -l "v1.*"
git describe --tags

describe stampa il tag più vicino più i commit successivi, es. v1.2.0-3-ga1b2c3d.

Submodule e worktree

Aggiungi un submodule#

git submodule add https://github.com/owner/lib.git vendor/lib
git commit -m "Add lib submodule"

Registra l'URL in .gitmodules e fissa un commit esatto dell'altro repository.

Scarica i submodule dopo il clone#

git clone --recurse-submodules <url>
git submodule update --init --recursive  # already cloned

Senza questo, le cartelle dei submodule sono vuote.

Porta i submodule all'ultimo commit#

git submodule update --remote
git commit -am "Bump submodules"

Scarica il branch tracciato di ciascun submodule; fai il commit dei nuovi riferimenti nel repository padre.

Lavora su due branch contemporaneamente#

git worktree add ../repo-hotfix hotfix
git worktree add -b review ../repo-review origin/main

Una seconda cartella di lavoro che condivide lo stesso repository; niente stash né secondo clone.

Elenca e rimuovi i worktree#

git worktree list
git worktree remove ../repo-hotfix
git worktree prune  # forget folders deleted by hand

remove si rifiuta se il worktree ha modifiche non committate (usa --force per forzare).

Pulizia

Anteprima dei file non tracciati che verrebbero eliminati#

git clean -n -d

Eseguilo sempre prima di git clean -f.

Elimina i file non tracciati#⚠ Elimina lavoro

git clean -fd  # untracked files and folders
git clean -fdx  # also ignored files (build output, .env!)

-x rimuove anche i file ignorati, compresa la configurazione locale come .env.

Recupero: Non recuperabile: questi file non sono mai stati in Git.

Elimina i branch già uniti in main#

git branch --merged main
git branch -d branch-a branch-b

Controlla prima l'elenco; -d rifiuta i branch non uniti, quindi provarlo è sicuro.

Rimuovi i branch di tracking remoti obsoleti#

git fetch --prune
git config set --global fetch.prune true

Elimina i riferimenti origin/* i cui branch sono stati cancellati sul server.

Velocizza un repository grande#

git maintenance start
git gc

maintenance start pianifica in background prefetch, commit-graph e repack; gc compatta gli oggetti ed elimina subito quelli non raggiungibili.

Configurazione e alias

Vedi tutte le impostazioni e da dove provengono#Git 2.46+

git config list --show-origin

Classico: git config --list --show-origin

Mostra i valori di sistema, globali e del repository con il file in cui si trova ciascuno.

Crea un alias#Git 2.46+

git config set --global alias.st "status -s"
git config set --global alias.lg "log --oneline --graph --all"

Classico: git config --global alias.st "status -s"

Poi git st e git lg. Anteponi ! per eseguire un comando di shell: alias.root "!pwd".

Impostazioni predefinite utili#Git 2.46+

git config set --global pull.rebase true
git config set --global push.autoSetupRemote true
git config set --global rerere.enabled true
git config set --global merge.conflictStyle zdiff3
git config set --global diff.algorithm histogram

Classico: git config --global pull.rebase true

Rebase al pull; upstream automatico al primo push (2.37+); memorizza le risoluzioni dei conflitti; mostra l'antenato comune nei conflitti (2.35+); diff più chiari.

Ignora file in tutti i repository#

git config set --global core.excludesFile ~/.gitignore_global

Classico: git config --global core.excludesFile ~/.gitignore_global

Per i file superflui di sistema operativo ed editor (.DS_Store, .idea/). Le regole specifiche del progetto vanno nel .gitignore del repository.

Nozioni di base di GitHub CLI (gh)

gh è lo strumento a riga di comando di GitHub, da installare separatamente da Git.

Accedi a GitHub#

gh auth login
gh auth setup-git  # let git use gh for HTTPS credentials

Apre un browser o accetta un token; funziona con github.com e GitHub Enterprise.

Crea un repository GitHub da una cartella locale#

gh repo create my-app --private --source=. --push

Crea il repository, lo aggiunge come origin e fa il push del branch corrente.

Clona per proprietario/nome#

gh repo clone owner/repo

Per un fork, aggiunge anche il repository padre come remote upstream.

Apri una pull request#

gh pr create --fill
gh pr create --draft --title "WIP: login" --body "…"

--fill usa i messaggi di commit per titolo e descrizione.

Fai il checkout della pull request di qualcuno#

gh pr checkout 123

Scarica il branch della PR (anche da fork) e ci passa.

Elenca, visualizza e unisci le pull request#

gh pr list
gh pr view 123 --web
gh pr merge 123 --squash --delete-branch

gh pr status mostra le PR che ti riguardano.

Crea ed elenca le issue#

gh issue create --title "Bug: …" --body "…"
gh issue list --assignee @me

gh issue view 42 --comments legge una discussione nel terminale.

Segui le esecuzioni di GitHub Actions#

gh run list
gh run watch

gh run view --log-failed stampa solo i passaggi non riusciti.

Ti serve un .gitignore di partenza? Usa il generatore di .gitignore. Vuoi confrontare due versioni di un file fuori da Git? Il confronto testi (diff) mostra le modifiche affiancate.

Un riferimento statico: la ricerca avviene nel tuo browser e nulla di ciò che digiti viene inviato altrove. Sfoglia tutti gli strumenti gratuiti.

Hai trovato un problema o qualcosa che potrebbe andare meglio? Leggiamo ogni messaggio e sistemiamo le cose in fretta.

Questa guida rapida a Git è organizzata per attività, non per comando, perché nessuno cerca “git reset --soft”: si cerca “annulla l'ultimo commit”. Trova ciò che stai cercando di fare, copia il comando e leggi la spiegazione di una riga su cosa modifica. La ricerca mette al primo posto le attività, quindi “elimina branch remoto” o “rinomina branch” porta dritto alla voce giusta.

I comandi che riscrivono la cronologia o buttano via lavoro sono segnalati, con una nota su cosa si può recuperare: quasi tutto ciò che è stato committato almeno una volta si può ritrovare con git reflog, mentre le modifiche non committate che scarti con restore, reset --hard o clean sono perse. Dove Git ora ha un comando più chiaro (git switch e git restore dalla 2.23, git config set e list dalla 2.46), viene mostrato per primo con la forma classica accanto, così il prontuario funziona sia che il tuo team abbia imparato Git l'anno scorso sia nel 2010. Verificato sul riferimento di git-scm.com per Git 2.56.

Come si usa

Scrivi ciò che vuoi fare nella casella di ricerca, per esempio “annulla l'ultimo commit”, “unstage” o “squash commit”, oppure fai clic su una delle attività comuni.
Leggi i badge prima di eseguire qualcosa: ambra significa che il comando riscrive la cronologia, rosso che può scartare lavoro. La nota di recupero spiega come tornare indietro.
Fai clic su Copia il comando. La copia esclude i commenti # così si incolla pulita in un terminale; sostituisci i segnaposto come a1b2c3d o feature/login con i tuoi valori.
Condividi una risposta precisa con il link # accanto a ogni attività, oppure stampa l'intero prontuario come PDF a due colonne.

Domande frequenti

Come si annulla l'ultimo commit in Git?

Se non l'hai ancora pushato, git reset --soft HEAD~1 rimuove il commit e lascia le modifiche nell'area di staging, mentre git reset HEAD~1 le lascia fuori dallo staging. git reset --hard HEAD~1 rimuove il commit e le sue modifiche. Se il commit è già stato pushato su un branch condiviso, usa invece git revert HEAD, che aggiunge un nuovo commit che lo annulla senza riscrivere la cronologia di nessuno.

Qual è la differenza tra git reset, git restore e git revert?

git restore modifica i file: scarta le modifiche nella working tree o le toglie dallo staging, e non sposta mai un branch. git reset sposta il branch corrente su un altro commit (e con --hard sovrascrive anche i tuoi file), quindi riscrive la cronologia. git revert crea un nuovo commit che applica l'opposto di uno precedente; la cronologia cresce soltanto, il che lo rende la scelta sicura sui branch usati da altre persone.

Come si rinomina un branch Git, in locale e sul remoto?

git branch -m nuovo-nome rinomina il branch su cui ti trovi (git branch -m vecchio nuovo per un altro). I remoti non hanno un'operazione di rinomina, quindi pusha il nuovo nome con git push -u origin nuovo-nome ed elimina il vecchio con git push origin --delete vecchio-nome. Su GitHub, rinominare il branch dall'interfaccia web aggiorna anche le pull request aperte.

Meglio git switch o git checkout?

Funzionano entrambi. git checkout fa due lavori che non c'entrano l'uno con l'altro, cambiare branch e ripristinare file, ed è per questo che Git 2.23 li ha separati in git switch e git restore. I nuovi comandi sono più chiari e più difficili da usare male (git checkout -- file scarta le modifiche senza avvisare), quindi questo prontuario li mostra per primi. git checkout non è deprecato e ogni comando qui riporta il suo equivalente classico.

Posso recuperare un commit dopo git reset --hard?

Di solito sì. Esegui git reflog, trova la riga precedente al reset ed esegui git reset --hard HEAD@{n} oppure crea un branch su quello SHA. Per impostazione predefinita, i commit restano raggiungibili tramite il reflog per 30 giorni da quando nient'altro punta a loro. Ciò che non si può recuperare è il lavoro non committato: le modifiche mai committate né messe in stash vengono sovrascritte per sempre.

Cosa fa git push --force-with-lease?

Sovrascrive il branch remoto solo se il remoto punta ancora dove lo ha visto il tuo ultimo fetch. Se nel frattempo qualcuno ha pushato, il push viene rifiutato invece di cancellare silenziosamente i suoi commit, che è ciò che fa il semplice --force. Usalo dopo un rebase o un amend su un branch che hai già pushato.

Quale comando per annullare? Decidi in base a dove si trova la modifica

• Hai modificato un file e vuoi eliminare la modifica: git restore file. Non recuperabile, perché non è mai stata committata.

• Hai messo qualcosa in staging per errore: git restore --staged file. Non si perde nulla; la modifica resta nel file.

• Hai committato ma non pushato: git reset --soft HEAD~1 per rifare il commit, oppure git commit --amend per correggerlo sul posto.

• Hai committato e pushato su un branch condiviso: git revert <sha>. Non fare reset di un branch che altri hanno già scaricato.

• Hai perso un commit, un branch o il risultato di un rebase andato male: git reflog, poi git branch rescued <sha>.

La regola di fondo: tutto ciò che riscrive i commit va bene finché i commit sono solo tuoi, e diventa un problema di tutti una volta condivisi.

Merge o rebase?

Entrambi portano le modifiche di un branch in un altro. Un merge registra che due cronologie si sono unite, con un commit di merge che ha due genitori; nulla viene riscritto, quindi è sempre sicuro sui branch condivisi. Un rebase riapplica i tuoi commit sopra l'altro branch, producendo una cronologia lineare come se fossi partito dall'ultimo commit, ma crea nuovi ID di commit, quindi chi ha già quelli vecchi deve riallinearsi.

Una convenzione di team comune: fai il rebase del tuo branch di funzionalità su main per restare aggiornato (git pull --rebase, oppure git rebase main) e fai il merge del branch finito in main tramite una pull request. Lo squash merge produce un solo commit per funzionalità su main; i merge normali conservano ogni commit e la forma del branch. Scegline uno per repository e impostalo nelle impostazioni dell'hosting, così la cronologia resta coerente.

Impostazioni di Git che vale la pena cambiare rispetto ai valori predefiniti

• pull.rebase true: git pull fa un rebase invece di creare commit di merge a ogni sincronizzazione.

• push.autoSetupRemote true (Git 2.37+): il primo git push di un nuovo branch ne imposta l'upstream, senza bisogno di -u.

• merge.conflictStyle zdiff3 (Git 2.35+): i marcatori di conflitto includono l'antenato comune, il che rende evidente la maggior parte dei conflitti.

• rerere.enabled true: Git ricorda come hai risolto un conflitto e riapplica la soluzione quando lo stesso conflitto si ripresenta durante un rebase.

• fetch.prune true: i branch remoti eliminati sul server spariscono anche in locale al fetch successivo.

• init.defaultBranch main: i nuovi repository partono su main.

Strumenti gratuiti correlati

Generatore di .gitignore — Combina template .gitignore per linguaggi, framework, editor e sistemi operativi in un unico file pulito.
Confronto testi (diff) — Confronta due versioni di un testo, di codice o di un file JSON e vedi esattamente quali righe, parole e caratteri sono cambiati.
Guida rapida Markdown — Ogni elemento Markdown con sorgente e anteprima, sintassi estesa (tabelle, elenchi di attività, note a piè di pagina, formule, Mermaid, avvisi), una tabella di compatibilità per 9 piattaforme e un'area di prova dal vivo.
Guida rapida alle regex — Ogni token delle espressioni regolari con un esempio funzionante, il supporto in JavaScript, PCRE/PHP, Python, Go, Java e .NET e un link Provalo che apre il tester regex già compilato.