Como encontrar o hash do branch no Git?

Dado um nome de branch local / remoto, como posso obter o hash do commit para o qual este branch aponta?

O comando git rev-parseé seu amigo, por exemplo:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... ou para uma filial de rastreamento remoto:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

Esse comando geralmente é muito útil, pois pode analisar qualquer uma das maneiras de especificar nomes de ramificações em git, como:

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

... etc.

Os hashes são armazenados em .git/refs/, por exemplo.git/refs/heads/master

Mas use programaticamente git rev-parseconforme sugerido por Mark Longair, pois é mais seguro.

Não se esqueça de que desde o Git 2.19 (2º trimestre de 2018), o Git prepara uma transição de hashes SHA1 para SHA2: consulte " Por que o Git não usa um SHA mais moderno? "

Com o Git 2.25 (Q1 2020), git rev-parseevolui e reflete esse possível novo hash.

Veja cometer fa26d5e , cometer cf02be8 , cometer 38ee26b , cometer 37ab8eb , cometer 0370b35 , cometer 0253e12 , cometer 45e2ef2 , cometer 79b0edc , cometer 840624f , cometer 32a6707 , cometer 440bf91 , cometer 0b408ca , cometer 2eabd38 (28 de outubro de 2019), e comprometer 1bcef51 , cometer ecde49b (05 out. 2019) por brian m. Carlson ( bk2204) .
^{(Fundido por Junio ​​C Hamano - gitster- no commit 28014c1, 10 de novembro de 2019)}

rev-parse: adicionar uma --show-object-formatopção

^{Assinado por: brian m. Carlson}

Adicione uma opção para imprimir o formato do objeto usado para entrada, saída ou armazenamento.
Isso permite que os scripts de shell descubram o algoritmo hash em uso.

Como o plano de transição permite vários algoritmos de entrada, documente que podemos fornecer vários resultados para entrada e o formato que os resultados podem assumir.
Embora não tenhamos suporte para isso agora, documentar antecipadamente significa que os autores de script podem preparar seus scripts para o futuro quando o fizermos.

A git rev-parsedocumentação agora inclui:

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

Mostra o formato do objeto (algoritmo hash) usado para o repositório para armazenamento dentro do .gitdiretório, entrada ou saída. Para entrada, vários algoritmos podem ser impressos, separados por espaço. Se não for especificado, o padrão é "armazenamento".

Com Git 2.29 (Q4 2020), você pode ter certeza de qual formato você deve usar para ler o hash commit de um branch (ou qualquer outro objeto).

Veja cometer e023ff0 , cometer 4feb562 , cometer 8a06d56 , cometer c49fe07 , cometer 02a32db , cometer ceaa4b3 , cometer eff45da , cometer b5b46d7 , cometer c5aecfc , cometer e74b606 , cometer 439d3a1 , cometer 6c2adf8 , cometer de5737c , cometer e0a646e , cometer 6ff6a67 , cometer 831279d , cometer b6e5005 , commit 287bb3a , commit 22f1824 , commit db00af9 ,comprometer 7187eb1 , cometer 98de0b2 , cometer a5587b8 , cometer 66b6d43 , cometer 2197f87 , cometer c0b65ea , cometer d62607d , cometer d482c23 , cometer 866be6e , cometer 4bacb6d , cometer 252a4ee , cometer 368f3cb , cometer abe3db1 , cometer 08fbc5d , cometer 11b6961 , cometer 9e3bd8a , cometer d827bce , commit 094a685 (29 jul 2020) por brian m. Carlson ( bk2204) .
Vejocommit 800e6a7 (29 de julho de 2020) por Johannes Schindelin ( dscho) .
^{(Fundido por Junio ​​C Hamano - gitster- no commit e0ad957 , 11 de agosto de 2020)}

docs: adicionar documentação para extensions.objectFormat

^{Assinado por: brian m. carlson Revisado
por: Eric Sunshine}

Documente a extensions.objectFormatdefinição de configuração.
Avise os usuários para não modificá-lo por conta própria.

git configagora inclui em sua página de manual :

extensions.objectFormat

Especifique o algoritmo de hash a ser usado.

Os valores aceitáveis ​​são sha1e> sha256.
Se não for especificado, sha1é assumido.
É um erro especificar essa chave, a menos que core.repositoryFormatVersionseja 1.

Observe que essa configuração só deve ser definida por git initou git clone.
Tentar alterá-lo após a inicialização não funcionará e produzirá problemas de difícil diagnóstico.

Para ficar claro, com Git 2.29 (quarto trimestre de 2020), a recente adição de suporte SHA-256 é marcada como experimental na documentação.

Veja o commit ff233d8 (16 de agosto de 2020) de Martin Ågren ( none) .
^{(Fundido por Junio ​​C Hamano - gitster- no commit d1ff741 , 24 de agosto de 2020)}

Documentation: marcar --object-format=sha256como experimental

^{Assinado por: Martin Ågren}

Após eff45daab8 (" repository: habilitar suporte SHA-256 por padrão", 2020-07-29, Git v2.29.0 - mesclagem listada no lote # 6 ), as compilações básicas do Git permitem que o usuário execute, por exemplo,

git init --object-format=sha256  

e hackear.
Esta pode ser uma boa maneira de ganhar experiência com o mundo SHA-256, por exemplo, para encontrar bugs que

GIT_TEST_DEFAULT_HASH=sha256 make test  

não localiza.

Mas é realmente um mundo separado: esses repositórios SHA-256 viverão totalmente separados do conjunto (agora bastante grande) de repositórios SHA-1.
Interagir além da fronteira é possível, em princípio, por exemplo, através de " diff+ apply" (ou " format-patch+ am"), mas mesmo isso tem suas limitações: Aplicar um diff SHA-256 em um repo SHA-1 funciona no caso simples, mas se você precisa recorrer -3, você está sem sorte.

Da mesma forma, " push+ pull" deve funcionar, mas você realmente estará operando principalmente deslocado do resto do mundo. Isso pode estar ok no momento em que você inicializar seu repositório, e pode estar ok por vários meses depois disso, mas pode chegar um dia em que você comece a se arrepender de usar [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 ter cavou-se em um buraco bastante profundo.

Atualmente, há tópicos em andamento para documentar nossos formatos de dados e protocolos em relação ao SHA-256 e, em alguns casos (midx e commit-graph), estamos considerando ajustar como os formatos de arquivo indicam qual formato de objeto usar.

Sempre que --object-formatfor mencionado em nossa documentação, vamos deixar claro que usá-lo com "sha256" é experimental.
Se mais tarde precisarmos explicar por que não podemos lidar com os dados que geramos em 2020, podemos sempre apontar para este parágrafo que estamos adicionando aqui.

Ao "incluir ::" - em uma pequena sinopse, devemos ser consistentes em toda a documentação e, eventualmente, diminuir gradualmente a severidade deste texto.
Um dia, podemos até usá-lo para começar a sair --object-format=sha1, mas não vamos nos precipitar ...

Também existe extensions.objectFormat, mas só é mencionado três vezes. Duas vezes onde estamos adicionando este novo aviso e no terceiro lugar já temos um aviso "não editar". A partir daí, os leitores interessados ​​devem, eventualmente, encontrar este novo que estamos adicionando aqui.

Como GIT_DEFAULT_HASHfornece outro ponto de entrada para essa funcionalidade, documente também a natureza experimental dela.

gitagora inclui em sua página de manual :

é usado em seu lugar. O padrão é "sha1". ESTA VARIÁVEL É EXPERIMENTAL! Veja --object-formatem git init.

object-format-disclaimeragora inclui em sua página de manual :

ESTA OPÇÃO É EXPERIMENTAL!
O suporte SHA-256 é experimental e ainda está em um estágio inicial.

Um repositório SHA-256 em geral não será capaz de> compartilhar trabalho com repositórios SHA-1 "normais".
Deve ser assumido que, por exemplo, formatos de arquivos internos Git em relação aos repositórios SHA-256 podem mudar de maneiras incompatíveis com versões anteriores.
Use apenas --object-format=sha256para fins de teste.

O mesmo Git 2.29 (Q4 2020) garante que " git clone" ^{( man )} funcionará quando alguém clona do repositório SHA-1, enquanto GIT_DEFAULT_HASHestá configurado para usar SHA-256 já.
Antes de 2.29, isso resultava em um repositório inutilizável que meio afirma ser um repositório SHA-256 com objetos SHA-1 e referências.
Isso foi corrigido.

Veja o commit 47ac970 (20 set 2020) de brian m. Carlson ( bk2204) .
^{(Fundido por Junio ​​C Hamano - gitster- no commit b28919c , 29 de setembro de 2020)}

builtin/clone: evitar falha com GIT_DEFAULT_HASH

^{Relatado por: Matheus Tavares
Assinado por: brian m. Carlson}

Se um usuário estiver clonando um repositório SHA-1 com GIT_DEFAULT_HASHdefinido como " sha256", então podemos terminar com um repositório onde a versão do formato do repositório é 0, mas a extensions.objectformatchave está definida como " sha256".
Isso é errado (o usuário tem um repositório SHA-1) e não funcional (porque a extensão não pode ser usada em um repositório v0).

Isso acontece porque em um clone, inicialmente configuramos o repositório e, em seguida, alteramos seu algoritmo com base no que o lado remoto nos diz que está usando.
Inicialmente configuramos o repositório como SHA-256 neste caso e, mais tarde, redefinimos a versão do repositório sem limpar a extensão.

Poderíamos sempre definir a extensão neste caso, mas isso significaria que nossos repositórios SHA-1 não eram compatíveis com versões mais antigas do Git, embora não haja razão para que não sejam.
E também não queremos inicializar o repositório como SHA-1 inicialmente, pois isso significa que se estivermos clonando um repositório vazio, teremos falhado em honrar a GIT_DEFAULT_HASHvariável e acabaremos com um repositório SHA-1, não um repositório SHA-256.

Nenhum deles é atraente, então vamos dizer ao código de inicialização do repositório se estamos fazendo uma reinicialização como esta e, em caso afirmativo, para limpar a extensão se estivermos usando SHA-1.
Isso garante que produzamos um repositório válido e funcional e não quebra nenhum de nossos outros casos de uso.