Git — Cheat Sheet

Tag: git, vcs, branching, rebase, merge, gitflow

Livello: intermedio

TL;DR: Riferimento rapido su branching strategy, risoluzione conflitti, rebase interattivo e comandi essenziali di recovery per colloqui tecnici.

Concetti chiave

Git registra snapshot immutabili dello stato dei file, non semplici differenze testuali.

Tre aree principali: Working Tree, Staging Area (Index) e Commit History (.git directory).

Fast-forward merge sposta solo il puntatore del branch target se la cronologia e lineare.

Three-way merge genera un commit esplicito di unione quando i rami divergono.

Rebase riscrive la cronologia applicando i commit di un branch in cima a un altro.

HEAD e il riferimento simbolico al branch o al commit attualmente attivo nel repository.

Detached HEAD indica che il puntatore e agganciato direttamente a un commit, non a un branch.

Reset altera la cronologia (soft mantiene lo stage, mixed preserva i file, hard distrugge modifiche).

Revert annulla le modifiche creando un nuovo commit senza riscrivere lo storico precedente.

Git reflog traccia ogni spostamento di HEAD e consente di recuperare commit apparentemente persi.

Domande tipiche e risposte pronte

Q: Quando scegli di fare un rebase invece di un merge?R: Uso rebase prima di aprire una PR per allineare il mio feature branch su main e mantenere la storia lineare; uso merge per integrare feature branch completati preservando il contesto storico dell'unione.

Q: Come recuperi modifiche o commit cancellati per errore con un hard reset?R: Consulto git reflog per individuare l'hash di HEAD precedente all'operazione distruttiva, quindi reimposto il branch o creo un ramo di recupero con git checkout o git reset su quell'hash.

Q: Qual e la differenza tra git fetch e git pull?R: Fetch scarica i nuovi dati e i puntatori dai rami remoti senza toccare il mio working tree locale, mentre pull esegue un fetch seguito immediatamente da un merge (o un rebase) sul branch corrente.

Insidie e errori comuni

Eseguire rebase o riscrivere la cronologia su branch condivisi o pubblici crea conflitti per il team.

git reset --hard su modifiche non salvate o non indicizzate distrugge il lavoro locale senza possibilita di recupero.

git push --force sovrascrive lo storico remoto; e preferibile usare --force-with-lease per proteggere il lavoro altrui.

Risolvere conflitti di merge lasciando residui di marker <<<<<<<, ======= o >>>>>>> nel sorgente.

Aggiungere accidentalmente file sensibili, credenziali o directory build nello stage senza un .gitignore adeguato.

Snippet e comandi

# Branching e allineamento
git checkout -b feature/login
git fetch origin
git rebase origin/main

# Rebase interattivo per compattare commit
git rebase -i HEAD~3

# Gestione dello stash
git stash push -m "wip-feature"
git stash pop

# Annullamento modifiche e recovery
git revert <commit_hash>
git reflog
git reset --hard HEAD@{1}

# Ispezione cronologia pulita
git log --oneline --graph --decorate -n 10

Da ripassare

[ ] Risoluzione di conflitti complessi durante rebase interattivo (git rebase --continue, --skip, --abort)

[ ] Meccanismo di pulizia e manutenzione del repository con git gc e git prune

[ ] Differenza tra squash merge, merge commit e rebase merge su repository remoti

[x] Flusso standard di branching e sincronizzazione remota