Introduzione

La maggior parte delle persone impara Git nel modo difficile, attraverso piccoli disastri. Questa pagina raccoglie gli errori più frequenti dei principianti e come evitarli (o recuperare). Leggila una volta ora e di nuovo dopo un mese di uso; il secondo passaggio avrà più senso.

Committare con l'identità sbagliata

Dimenticare di impostare user.email per repository fa trapelare indirizzi personali nei commit di lavoro. Imposta sempre un'identità per-repo nei clone di lavoro:

git config user.email "[email protected]"
git log -1 --pretty=format:"%an <%ae>"

Committare segreti

Le chiavi API e i file .env nei commit vivono per sempre, anche dopo una "cancellazione" successiva. Aggiungi una entry in .gitignore prima del primo commit, e ruota immediatamente qualsiasi credenziale trapelata. Strumenti come git-secrets e gitleaks possono girare come pre-commit hook.

Force-push sopra i compagni di team

git push --force riscrive la storia sul remote, cancellando i commit di altre persone. Preferisci --force-with-lease, che rifiuta di sovrascrivere se il remote si è mosso:

git push --force-with-lease

Fraintendere pull

git pull è fetch + merge (o rebase). Eseguirlo con modifiche non committate può produrre merge commit sorprendenti. O committa, fai stash, o imposta un default sensato:

git config --global pull.rebase true
git config --global pull.ff only

Modificare detached HEAD senza accorgersene

Fare checkout di un tag o hash di commit ti lascia in detached HEAD. I nuovi commit lì sono irraggiungibili una volta che ti sposti. Crea sempre prima un branch:

git switch -c hotfix v1.2.3

Confondere reset, revert e restore

• git restore cambia la working tree o l'index; sicuro.
• git revert crea un nuovo commit che annulla un altro; sicuro e condivisibile.
• git reset --hard sposta il branch e scarta il lavoro; distruttivo.

Committare file enormi

Un video da 500 MB in un commit è permanente. Usa Git LFS per binari sopra qualche megabyte, e tieni gli artefatti di build completamente fuori dal repository.

Toolkit di recupero

git reflog
git fsck --lost-found
git stash list

Il reflog registra ogni movimento di HEAD per 90 giorni di default; quasi ogni commit "perso" può essere recuperato da lì.

Leggere male lo status

L'output di git status ha strati sottili. "Changes not staged for commit" significa file tracciati modificati nella working tree. "Changes to be committed" significa in stage. "Untracked files" significa che Git non li ha mai visti. Una confusione comune: modificare un file dopo averlo messo in stage lo mostra in entrambe le liste con contenuto diverso; solo ciò che è in stage va nel commit. Esegui git diff (working vs index) e git diff --staged (index vs HEAD) finché le tre aree non si capiscono.

git status -sb
git diff --staged --stat

Errori comuni

Farsi prendere dal panico ed eseguire rm -rf .git quando qualcosa sembra sbagliato. Fermati. Fai prima un backup della directory. Quasi ogni errore Git è recuperabile attraverso il reflog o lo stash. La singola abitudine più importante per i principianti: esegui git status prima e dopo ogni comando che cambia stato, ed esegui git log --oneline --all --graph quando qualcosa sembra strano.