Git refs: An overview

È particolarmente utile quando si scrivono script personalizzati che accettano un riferimento al commit. Invece di analizzare manualmente il riferimento al commit, puoi affidare a git rev-parse la normalizzazione dell'input.

Un riferimento rappresenta un modo indiretto di fare riferimento a un commit. Puoi considerarlo un alias intuitivo per un hash di commit. Questo è il meccanismo interno di Git per rappresentare branch e tag.

I riferimenti sono archiviati come normali file di testo nella directory .git/refs, dove il file denominato .git di solito è chiamato .git. Per esplorare i riferimenti in uno dei tuoi repository, vai a .git/refs. Dovresti vedere la seguente struttura, che tuttavia contiene file diversi a seconda dei branch, dei tag e dei remoti presenti nel repository:

La directory head definisce tutti i branch locali nel repository. Ogni nome di file corrisponde al nome del branch corrispondente e all'interno del file è presente un hash di commit, che è la posizione della punta del branch. Per verificarlo, prova a eseguire i due comandi seguenti dalla directory principale del repository Git:

L'hash di commit restituito dal comando cat deve corrispondere all'ID di commit visualizzato da git log.

Per cambiare la posizione del branch main, tutto ciò che Git deve fare è cambiare il contenuto del file refs/heads/main. Allo stesso modo, per creare un nuovo branch è sufficiente scrivere un hash di commit in un nuovo file. Questo è uno dei motivi per cui i branch Git sono così leggeri rispetto a SVN.

La directory tags funziona esattamente allo stesso modo, ma contiene tag anziché branch. La directory remotes elenca tutti i repository remoti che hai creato con git remote come sottodirectory separate. All'interno di ciascun repository troverai tutti i branch remoti che sono stati recuperati nel repository.

Quando passi un riferimento a un comando Git, puoi definire il nome completo del riferimento o utilizzare un nome breve e lasciare che sia Git a eseguire la ricerca di un riferimento corrispondente. Dovresti già avere familiarità con i nomi brevi per i riferimenti, poiché sono quelli che utilizzi ogni volta che fai riferimento a un branch per nome.

L'argomento some-feature nel comando riportato sopra è in realtà un nome abbreviato per il branch. Git lo risolve in refs/heads/some-feature prima di utilizzarlo. Puoi anche specificare il riferimento completo nella riga di comando, come indicato di seguito:

In questo modo eviti qualsiasi ambiguità riguardo alla posizione del riferimento. È necessario, ad esempio, se fossero presenti sia un tag sia un branch denominati entrambi some-feature. Tuttavia, se utilizzi convenzioni di denominazione corrette, l'ambiguità tra tag e branch in genere non dovrebbe costituire un problema.

Esamineremo altri nomi di riferimento completi nella sezione Specifiche dei riferimenti.

Per i repository di grandi dimensioni, Git esegue periodicamente una garbage collection per rimuovere oggetti non necessari e comprime i riferimenti in un unico file per ottimizzare le prestazioni. Puoi forzare questa compressione con il comando garbage collection:

Questo comando sposta tutti i singoli file dei branch e dei tag presenti nella cartella refs in un unico file denominato packed-refs, che si trova in cima alla directory .git . Se apri questo file, troverai una mappatura degli hash di commit ai riferimenti:

All'esterno, la normale funzionalità di Git non sarà in alcun modo interessata. Tuttavia, se ti stai chiedendo perché la cartella .git/refs è vuota, sappi che i riferimenti sono finiti in questo file.

Oltre alla directory refs, sono presenti alcuni riferimenti speciali che risiedono nella directory .git . Sono elencati di seguito:

• HEAD: il commit/branch attualmente sottoposto a checkout.
• FETCH_HEAD: il branch recuperato più di recente da un repository remoto.
• ORIG_HEAD: un riferimento di backup a HEAD prima che venga sottoposto a modifiche drastiche.
• MERGE_HEAD: i commit sottoposti a merge nel branch corrente con git merge.
• CHERRY_PICK_HEAD: il commit per il quale hai eseguito il cherry-pick.

Questi riferimenti sono tutti creati e aggiornati da Git quando necessario. Ad esempio, il comando git pull esegue prima git fetch, che aggiorna il riferimento FETCH_HEAD. Quindi, esegue git merge FETCH_HEAD per completare il checkout dei rami recuperati nel repository. Naturalmente, puoi utilizzarli tutti come qualsiasi altro riferimento, come sicuramente hai fatto con HEAD.

Il contenuto di questi file è diverso a seconda del tipo e dello stato del repository. Il riferimento HEAD può contenere un riferimento simbolico, che è semplicemente un riferimento a un altro riferimento anziché un hash di commit, o un hash di commit. Ad esempio, dai un'occhiata al contenuto di HEAD quando sei nel branch main:

L'output sarà ref: refs/heads/main, il che significa che HEAD punta al riferimento refs/heads/main. È in questo modo che Git sa che è stato effettuato il checkout del branch main. Se dovessi passare a un altro branch, il contenuto di HEAD verrebbe aggiornato per riflettere il nuovo branch. Tuttavia, se dovessi effettuare il checkout di un commit invece che di un branch, HEAD conterrebbe un hash di commit invece di un riferimento simbolico. È in questo modo che Git sa di essere in uno stato HEAD scollegato.

Nella maggior parte dei casi, HEAD è l'unico riferimento che utilizzerai direttamente. Gli altri in genere sono utili solo per la scrittura di script di livello inferiore che devono eseguire l'hook ai meccanismi interni di Git.

Una specifica di riferimento mappa un branch nel repository locale a un branch in un repository remoto. In questo modo è possibile gestire i branch remoti utilizzando i comandi Git locali e configurare alcuni comportamenti git push e git fetch avanzati.

Una specifica di riferimento è specificata come [+]＜src＞:＜dst＞. Il parametro è il branch di origine nel repository locale e il parametro è il branch di destinazione nel repository remoto. Il segno + opzionale serve a forzare l'esecuzione di un aggiornamento non rapido da parte del repository remoto.