Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

La merge base di due commit è il loro miglior antenato comune: la fondazione che Git usa per i merge a tre vie. Scegliere la base giusta è ciò che fa funzionare davvero i merge "automatici".

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

Quando Git non può combinare automaticamente due modifiche alla stessa regione di un file, lascia marker di conflitto nella copia di lavoro e ti permette di risolvere manualmente. I marker non sono magia; registrano esattamente cosa ha fatto ogni lato relativo a una base comune.

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

git push carica commit a un remote e aggiorna i ref di quel remote. A differenza del fetch, modifica lo stato sul server, quindi esistono meccanismi di sicurezza per prevenire la sovrascrittura del lavoro di altre persone.

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

git pull è zucchero per git fetch seguito dall'integrazione del branch upstream nel branch corrente. Il passo di integrazione è un merge (default) o un rebase.

I due passi

  1. git fetch <remote> <refspec>: scarica e aggiorna i ref di tracking.
  2. Se pull.rebase è false: git merge FETCH_HEAD.
  3. Se pull.rebase è true: git rebase FETCH_HEAD.

Sequenza manuale equivalente:

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

git fetch è l'operazione di rete che scarica nuovi oggetti e aggiorna i ref di tracking remoto. Non cambia i tuoi branch o la working tree, il che lo rende il comando "cosa c'è di nuovo?" più sicuro.

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

git clone sembra una sola operazione ma in realtà ne compone diverse. Capire i passi aiuta quando si risolvono problemi di clone parziali, clone lenti o default sorprendenti.

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

Git supporta due tipi di tag: lightweight, che sono solo ref che puntano a commit, e annotated, che sono oggetti Git completi con metadati. Usa i tag annotated per le release.

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

Git tiene diversi ref speciali "ausiliari" in .git/ per registrare lo stato durante operazioni multi-step. Conoscerli trasforma recuperi spaventosi in one-liner.

ORIG_HEAD

ORIG_HEAD viene impostato ogni volta che un'operazione "pericolosa" sposta HEAD di molto: merge, rebase, reset, am. Cattura la punta precedente così puoi disfare:

git merge feature
# decidi che era un errore
git reset --hard ORIG_HEAD

Stesso trucco dopo un brutto rebase o reset:

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

Git memorizza gli oggetti in due formati: loose (un file per oggetto sotto .git/objects/xx/yyyy...) e packed (molti oggetti in un singolo file .pack con un compagno .idx). I pack sono molto più efficienti su disco e in rete.

Da Anonimo (non verificato) , 29 Aprile 2026

Introduzione

Un commit Git fa riferimento a zero, uno o più commit parent. L'intera storia è un grafo aciclico orientato (DAG) di questi link parent. Branch e tag sono semplicemente etichette sui nodi di questo grafo.

Anatomia di un link parent

git cat-file -p HEAD
# tree 9f1a...
# parent b2c3...
# parent d4e5...        (solo sui merge commit)
# author Ada ...
# committer Ada ...

Un parent: storia lineare. Due parent: un merge. Zero parent: un commit root. Tre o più: un merge octopus.