Come trovare l'hash del ramo in Git?

Dato un nome di ramo locale / remoto, come posso ottenere l'hash del commit a cui punta questo ramo?

Il comando git rev-parseè tuo amico, ad esempio:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... o per un ramo di monitoraggio remoto:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

Questo comando è generalmente molto utile, poiché può analizzare qualsiasi modo di specificare i nomi dei rami git, come ad esempio:

git rev-parse master~3
git rev-parse HEAD@{2.days.ago}

... eccetera.

Gli hash vengono archiviati in .git/refs/, ad es.git/refs/heads/master

Ma usa programmaticamente git rev-parsecome suggerito da Mark Longair in quanto è più sicuro.

Non dimenticare che da Git 2.19 (Q2 2018), Git prepara una transizione dagli hash SHA1 a SHA2: vedi " Perché Git non usa SHA più moderno? "

Con Git 2.25 (Q1 2020), si git rev-parseevolve e riflette quel possibile nuovo hash.

Vedere commettere fa26d5e , commettere cf02be8 , commettere 38ee26b , commettere 37ab8eb , commettere 0370b35 , commettere 0253e12 , commettere 45e2ef2 , commettere 79b0edc , commettere 840624f , commettere 32a6707 , commettere 440bf91 , commettere 0b408ca , commettere 2eabd38 (28 Ottobre 2019), e impegnarsi 1bcef51 , commettono ecde49b (05 ottobre 2019) di brian m. carlson ( bk2204) .
^{(Fuso da Junio ​​C Hamano - gitster- nel commit 28014c1, 10 nov 2019)}

rev-parse: aggiungi --show-object-formatun'opzione

^{Firmato da: brian m. carlson}

Aggiungere un'opzione per stampare il formato dell'oggetto utilizzato per l'input, l'output o l'archiviazione.
Ciò consente agli script della shell di scoprire l'algoritmo hash in uso.

Poiché il piano di transizione consente più algoritmi di input, documenta che possiamo fornire più risultati per l'input e il formato che i risultati possono assumere.
Anche se ora non lo supportiamo, documentarlo in anticipo significa che gli autori di script possono rendere i loro script a prova di futuro per quando lo faremo.

La git rev-parsedocumentazione ora include:

--show-object-format[=(storage|input|output)]:

Mostra il formato dell'oggetto (algoritmo hash) utilizzato per il repository per l'archiviazione all'interno della .gitdirectory, dell'input o dell'output. Per l'input, possono essere stampati più algoritmi, separati da spazi. Se non specificato, il valore predefinito è "archiviazione".

Con Git 2.29 (Q4 2020), puoi assicurarti quale formato devi usare per leggere l'hash commit di un ramo (o qualsiasi altro oggetto).

Vedere commettere e023ff0 , commettere 4feb562 , commettere 8a06d56 , commettere c49fe07 , commettere 02a32db , commettere ceaa4b3 , commettere eff45da , commettere b5b46d7 , commettere c5aecfc , commettere e74b606 , commettere 439d3a1 , commettere 6c2adf8 , commettere de5737c , commettere e0a646e , commettere 6ff6a67 , commettere 831279d , commettono b6e5005 , commit 287bb3a , commit 22f1824 , commit db00af9 ,commit 7187eb1 , commit 98de0b2 , commit a5587b8 , commit 66b6d43 , commit 2197f87 , commit c0b65ea , commit d62607d , commit d482c23 , commit 866be6e , commit 4bacb6d , commit 252a4ee , commit 368f3cb , commit abe3db1 , commit 08fbc5d , commit 11b6961 , commit 9e3bd8a , commit d827bce , commit 094a685 (29 lug 2020) di brian m. carlson ( bk2204) .
Vederecommit 800e6a7(29 lug 2020) di Johannes Schindelin ( dscho) .
^{(Fuso da Junio ​​C Hamano - gitster- in commit e0ad957 , 11 agosto 2020)}

docs: aggiungi documentazione per extensions.objectFormat

^{Firmato da: brian m. carlson
Recensito da: Eric Sunshine}

Documenta l' extensions.objectFormatimpostazione di configurazione.
Avvisare gli utenti di non modificarlo da soli.

git configora include nella sua pagina man :

extensions.objectFormat

Specifica l'algoritmo hash da utilizzare.

I valori accettabili sono sha1e> sha256.
Se non specificato, sha1si presume.
È un errore specificare questa chiave a meno che non core.repositoryFormatVersionsia 1.

Notare che questa impostazione deve essere impostata solo da git inito git clone.
Il tentativo di modificarlo dopo l'inizializzazione non funzionerà e produrrà problemi difficili da diagnosticare.

Per essere chiari, con Git 2.29 (Q4 2020), la recente aggiunta del supporto SHA-256 è contrassegnata come sperimentale nella documentazione.

Vedere commit ff233d8 (16 agosto 2020) di Martin Ågren ( none) .
^{(Fuso da Junio ​​C Hamano - gitster- in commit d1ff741 , 24 agosto 2020)}

Documentation: contrassegna --object-format=sha256come sperimentale

^{Firmato da: Martin Ågren}

Dopo eff45daab8 (" repository: abilita supporto SHA-256 per impostazione predefinita", 2020-07-29, Git v2.29.0 - unione elencata nel batch # 6 ), le build vanilla di Git consentono all'utente di eseguire, ad esempio,

git init --object-format=sha256  

e hackerare.
Questo può essere un buon modo per acquisire esperienza con il mondo SHA-256, ad esempio per trovare bug che

GIT_TEST_DEFAULT_HASH=sha256 make test  

non macchia.

Ma in realtà è un mondo separato: tali repository SHA-256 vivranno completamente separati dal set (ormai abbastanza grande) di repository SHA-1.
L'interazione oltre confine è possibile in linea di principio, ad esempio tramite " diff+ apply" (o " format-patch+ am"), ma anche questo ha i suoi limiti: applicare una differenza SHA-256 in un repo SHA-1 funziona nel caso semplice, ma se tu bisogno di ricorrere -3, sei sfortunato.

Allo stesso modo, " push+ pull" dovrebbe funzionare, ma opererai per lo più in compensazione rispetto al resto del mondo. Potrebbe essere ok quando inizializzi il tuo repository, e potrebbe [andar bene per diversi mesi dopo, ma potrebbe arrivare un giorno in cui inizi a pentirti del tuo uso di git init --object-format = sha256 ](https://github.com/git/git/blob/ff233d8dda12657a90d378f2b403bc6c85838c59/Documentation/git-init.txt#L52)<sup>([man](https://git-scm.com/docs/git-init#Documentation/git-init.txt---object-formatltformatgt))</sup>e hai ti sei scavato in un buco abbastanza profondo.

Ci sono attualmente argomenti in corso per documentare i nostri formati di dati e protocolli riguardanti SHA-256 e in alcuni casi (midx e commit-graph), stiamo valutando di modificare il modo in cui i formati di file indicano quale formato oggetto utilizzare.

Ovunque --object-formatsia menzionato nella nostra documentazione, chiariamo che usarlo con "sha256" è sperimentale.
Se in seguito avremo bisogno di spiegare perché non possiamo gestire i dati che abbiamo generato nel 2020, possiamo sempre indicare questo paragrafo che stiamo aggiungendo qui.

Con "includi ::" - in un piccolo blurb, dovremmo essere in grado di essere coerenti in tutta la documentazione e alla fine possiamo gradualmente attenuare la gravità di questo testo.
Un giorno, potremmo persino usarlo per iniziare a eliminare gradualmente --object-format=sha1, ma non anticipiamo noi stessi ...

C'è anche extensions.objectFormat, ma è menzionato solo tre volte. Due volte in cui stiamo aggiungendo questo nuovo disclaimer e nel terzo punto abbiamo già un avviso "non modificare". Da lì, i lettori interessati dovrebbero eventualmente trovare questo nuovo che stiamo aggiungendo qui.

Poiché GIT_DEFAULT_HASHfornisce un altro punto di ingresso a questa funzionalità, documenta anche la sua natura sperimentale.

gitora include nella sua pagina man :

viene utilizzato invece. L'impostazione predefinita è "sha1". QUESTA VARIABILE È SPERIMENTALE! Vedi --object-formatin git init.

object-format-disclaimerora include nella sua pagina man :

QUESTA OPZIONE È SPERIMENTALE!
Il supporto SHA-256 è sperimentale e ancora in una fase iniziale.

Un repository SHA-256 in generale non sarà in grado di> condividere il lavoro con i repository SHA-1 "normali".
Si dovrebbe presumere che, ad esempio, i formati di file interni di Git in relazione ai repository SHA-256 possano cambiare in modi incompatibili all'indietro.
Utilizzare solo --object-format=sha256a scopo di test.

Lo stesso Git 2.29 (Q4 2020) fa in modo che " git clone" ^{( man )} funzionerà quando uno clona dal repository SHA-1, mentre GIT_DEFAULT_HASHè già impostato per usare SHA-256.
Prima della 2.29, ciò si traduceva in un repository inutilizzabile che per metà dichiara di essere un repository SHA-256 con oggetti e ref SHA-1.
Questo è stato corretto.

Vedere commit 47ac970 (20 settembre 2020) di brian m. carlson ( bk2204) .
^{(Unificato da Junio ​​C Hamano - gitster- in commit b28919c , 29 set 2020)}

builtin/clone: evita il fallimento con GIT_DEFAULT_HASH

^{Segnalato da: Matheus Tavares
Autografato da: brian m. carlson}

Se un utente sta clonando un repository SHA-1 con GIT_DEFAULT_HASHimpostato su " sha256", allora possiamo ritrovarci con un repository in cui la versione del formato del repository è 0 ma la extensions.objectformatchiave è impostata su " sha256".
Questo è sbagliato (l'utente ha un repository SHA-1) e non funzionale (perché l'estensione non può essere utilizzata in un repository v0).

Ciò accade perché in un clone, inizialmente impostiamo il repository, quindi cambiamo il suo algoritmo in base a ciò che il lato remoto ci dice che sta utilizzando.
Inizialmente abbiamo impostato il repository come SHA-256 in questo caso, quindi in seguito abbiamo ripristinato la versione del repository senza cancellare l'estensione.

Potremmo sempre impostare l'estensione in questo caso, ma ciò significherebbe che i nostri repository SHA-1 non erano compatibili con le versioni precedenti di Git, anche se non c'è motivo per cui non dovrebbero esserlo.
Inoltre, non vogliamo inizializzare il repository come SHA-1 inizialmente, poiché ciò significa che se stiamo clonando un repository vuoto, non saremo riusciti a rispettare la GIT_DEFAULT_HASHvariabile e finiremo con un repository SHA-1, un repository SHA-256.

Nessuno di questi è attraente, quindi diciamo al codice di inizializzazione del repository se stiamo eseguendo un reinit come questo e, in tal caso, per cancellare l'estensione se stiamo usando SHA-1.
Questo ci assicura di produrre un repository valido e funzionale e non interrompe nessuno dei nostri altri casi d'uso.