Git에서 분기의 해시를 찾는 방법은 무엇입니까?

로컬 / 원격 브랜치 이름이 주어지면이 브랜치가 가리키는 커밋의 해시를 어떻게 얻을 수 있습니까?

명령 git rev-parse은 친구입니다. 예 :

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... 또는 원격 추적 분기의 경우 :

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

이 명령은 git다음과 같이 에서 분기 이름을 지정하는 모든 방법을 구문 분석 할 수 있으므로 일반적으로 매우 유용합니다 .

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

... 등

해시는 아래에 저장됩니다 .git/refs/. 예 :.git/refs/heads/master

그러나 git rev-parseMark Longair가 제안한대로 프로그래밍 방식으로 사용 하면 더 안전합니다.

Git 2.19 (2018 년 2 분기) 이후 Git은 SHA1 해시에서 SHA2 로의 전환을 준비합니다. " Git에서 더 최신 SHA를 사용하지 않는 이유는 무엇입니까? "를 참조하십시오.

Git 2.25 (2020 년 1 분기)에서는 git rev-parse가능한 새로운 해시를 발전시키고 반영합니다.

참조 fa26d5e 커밋 , cf02be8 커밋 , 38ee26b 커밋 , 커밋 37ab8eb , 0370b35 커밋 , 0253e12 커밋 , 45e2ef2 커밋 , 79b0edc 커밋 , 840624f 커밋 , 32a6707 커밋 , 440bf91 커밋 , 0b408ca 커밋 , 2eabd38 커밋 (2019 10월 28일을), 및 1bcef51 커밋 , 커밋 ecde49b (2019 년 10 월 5 일) by brian m. 칼슨 ( bk2204) .
^{(의해 병합 Junio C 하마노 - gitster- 에 28014c1 커밋, 2019 년 11 월 10 일)}

rev-parse: --show-object-format옵션 추가

^{서명자 : Brian M. Carlson}

입력, 출력 또는 저장에 사용되는 개체 형식을 인쇄하는 옵션을 추가합니다.
이를 통해 쉘 스크립트가 사용중인 해시 알고리즘을 검색 할 수 있습니다.

전환 계획은 여러 입력 알고리즘을 허용하므로 입력에 대해 여러 결과를 제공 할 수 있음을 문서화하고 결과가 취할 수있는 형식을 문서화하십시오.
지금은이를 지원하지 않지만 초기에 문서화하면 스크립트 작성자가 우리가 지원할 때 스크립트를 미래에 대비할 수 있습니다.

이제 git rev-parse문서 에는 다음이 포함됩니다.

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

.git디렉토리, 입력 또는 출력 내부에 저장하기 위해 저장소에 사용되는 객체 형식 (해시 알고리즘)을 표시합니다 . 입력의 경우 여러 알고리즘을 공백으로 구분하여 인쇄 할 수 있습니다. 지정되지 않은 경우 기본값은 "저장소"입니다.

Git 2.29 (Q4 2020)를 사용하면 브랜치 (또는 기타 객체)의 해시 커밋을 읽는 데 사용해야하는 형식을 확인할 수 있습니다.

참조 e023ff0 커밋 , 4feb562 커밋 , 8a06d56 커밋 , c49fe07 커밋 , 02a32db 커밋 , ceaa4b3 커밋 , eff45da 커밋 , b5b46d7 커밋 , 커밋 c5aecfc , e74b606 커밋 , 439d3a1 커밋 , 6c2adf8 커밋 , de5737c 커밋 , 커밋 e0a646e , 6ff6a67 커밋 , 831279d 커밋 , 커밋 b6e5005 , 커밋 287bb3a , 커밋 22f1824 , 커밋 db00af9 ,7187eb1 커밋 , 98de0b2 커밋 , a5587b8 커밋 , 66b6d43 커밋 , 2197f87 커밋 , c0b65ea 커밋 , d62607d 커밋 , 커밋 d482c23 , 866be6e 커밋 , 4bacb6d 커밋 , 252a4ee 커밋 , 368f3cb 커밋 , 커밋 abe3db1 , 08fbc5d 커밋 , 11b6961 커밋 , 9e3bd8a 커밋 , d827bce 커밋 , commit 094a685 (2020 년 7 월 29 일) by brian m. 칼슨 ( bk2204) .
보다commit 800e6a7 (2020 년 7 월 29 일) by Johannes Schindelin ( dscho) .
^{(Merged by Junio ​​C gitsterHamano -- in commit e0ad957 , 11 Aug 2020)}

docs: 문서 추가 extensions.objectFormat

^{서명자 : Brian M. carlson
검토 자 : Eric Sunshine}

extensions.objectFormat구성 설정을 문서화하십시오 .
사용자가 직접 수정하지 않도록 경고합니다.

git config이제 man 페이지에 포함됩니다 .

extensions.objectFormat

사용할 해시 알고리즘을 지정하십시오.

허용되는 값은 sha1및> sha256입니다.
지정하지 않으면 sha1가정합니다. 1
이 아니면이 키를 지정하는 것은 오류 core.repositoryFormatVersion입니다.

이 설정은 git init또는 로만 설정해야합니다 git clone.
초기화 후 변경을 시도하면 작동하지 않으며 진단하기 어려운 문제가 발생합니다.

명확하게 말하면 Git 2.29 (2020 년 4 분기)에서 최근 추가 된 SHA-256 지원은 문서에서 실험적인 것으로 표시됩니다 .

Martin Ågren ( )의 commit ff233d8 (2020 년 8 월 16 일)을 참조하십시오 . ^{(Merged by Junio ​​C Hamano -- in commit d1ff741 , 24 Aug 2020)}none
gitster

Documentation: --object-format=sha256실험용으로 표시

^{서명자 : Martin Ågren}

후 eff45daab8 ( " repository: 2020년 7월 29일을 기본적으로 SHA-256 지원을 활성화", 힘내 v2.29.0 - 병합 에 나열된 배치 # 6 ), 바닐라 망할 놈의 빌드를 실행하는 사용자를 활성화, 예를 들면,

git init --object-format=sha256  

해킹하세요.
이것은 SHA-256 세계에 대한 경험을 쌓는 좋은 방법이 될 수 있습니다.

GIT_TEST_DEFAULT_HASH=sha256 make test  

발견하지 않습니다.

그러나 실제로는 별도의 세계입니다. 이러한 SHA-256 저장소는 (현재 상당히 큰) SHA-1 저장소 집합과 완전히 분리되어 있습니다.
원칙적으로는 " diff+ apply"(또는 " format-patch+ am")를 통해 국경을 넘어 상호 작용할 수 있지만 그 제한 사항이 있습니다. 에 의지해야합니다 -3. 운이 좋지 않습니다.

마찬가지로 " push+ pull"도 작동하지만 실제로는 나머지 세계와는 상쇄되어 작동합니다. 리포지토리를 초기화 할 때는 괜찮을 수 있으며 그 후 몇 달 동안은 괜찮을 수 있지만 [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>있습니다. 상당히 깊은 구멍에 자신을 파헤 쳤습니다.

현재 SHA-256에 관한 데이터 형식 및 프로토콜을 문서화하기위한 주제가 있으며 일부 경우 (midx 및 commit-graph) 파일 형식이 사용할 개체 형식을 나타내는 방법을 조정하는 것을 고려하고 있습니다.

--object-format문서에서 언급 된 모든 곳 에서 "sha256"과 함께 사용하는 것은 실험적이라는 것을 분명히합시다.
나중에 2020 년에 생성 한 데이터를 처리 할 수없는 이유를 나중에 설명해야하는 경우 여기에 추가하는이 단락을 항상 가리킬 수 있습니다.

"include ::"-작은 설명으로 문서 전체에서 일관성을 유지할 수 있어야하며 결국이 텍스트의 심각도를 점차적으로 낮출 수 있습니다.
언젠가는 그것을 사용하여 단계적 단계를 시작할 수도 --object-format=sha1있지만 우리 자신보다 앞서 나가지 말자 ...

도 extensions.objectFormat있지만 세 번만 언급되었습니다. 이 새로운 고지 사항을 두 번 추가하고 세 번째 부분에는 이미 "수정 안 함"경고가 표시됩니다. 거기에서 관심있는 독자들은 결국 여기에 추가 할 새로운 것을 찾아야합니다.

때문에 GIT_DEFAULT_HASH이 기능에 다른 진입 점을 제공, 너무 그것의 실험적인 성격을 문서화합니다.

git이제 man 페이지에 포함됩니다 .

대신 사용됩니다. 기본값은 "sha1"입니다. 이 변수는 실험적입니다! 보기 --object-format에서 git init.

object-format-disclaimer이제 man 페이지에 포함됩니다 .

이 옵션은 실험적입니다!
SHA-256 지원은 실험적이며 아직 초기 단계입니다.

일반적으로 SHA-256 저장소는 "일반"SHA-1 저장소와 작업을 공유 할 수 없습니다.
예를 들어, SHA-256 저장소와 관련된 Git 내부 파일 형식이 이전 버전과 호환되지 않는 방식으로 변경 될 수 있다고 가정해야합니다. 테스트 목적으로
만 사용하십시오 --object-format=sha256.

동일한 Git 2.29 (2020 년 4 분기) 에서는 SHA-1 저장소에서 하나의 복제본이 생성 될 때 " git clone" ^{( man )} 이 작동 하는지 확인하고 GIT_DEFAULT_HASH이미 SHA-256을 사용하도록 설정되어 있습니다.
2.29 이전에는 SHA-1 객체 및 refs가있는 SHA-256 저장소라고 절반이 주장하는 사용할 수없는 저장소가 발생했습니다.
이것은 수정되었습니다.

Brian M의 commit 47ac970 (2020 년 9 월 20 일)을 참조하십시오 . 칼슨 ( bk2204) .
^{(Merged by Junio ​​C gitsterHamano -- in commit b28919c , 29 Sep 2020)}

builtin/clone: 실패 방지 GIT_DEFAULT_HASH

^{보고자 : Matheus Tavares
서명자 : brian m. Carlson}

사용자가 GIT_DEFAULT_HASH" sha256" 로 설정된 SHA-1 저장소를 복제하는 경우 저장소 형식 버전이 0이지만 extensions.objectformat키가 " sha256" 로 설정된 저장소로 끝날 수 있습니다 .
이것은 잘못되었고 (사용자에게 SHA-1 저장소가 있음) 작동하지 않습니다 (확장 프로그램을 v0 저장소에서 사용할 수 없기 때문에).

이것은 클론에서 처음에 리포지토리를 설정 한 다음 원격 측이 사용하고 있다고 알려주는 것에 따라 알고리즘을 변경하기 때문에 발생합니다.
이 경우 처음에 저장소를 SHA-256으로 설정 한 다음 나중에 확장을 지우지 않고 저장소 버전을 재설정했습니다.

이 경우에는 항상 확장을 설정할 수 있었지만 이는 SHA-1 리포지토리가 이전 Git 버전과 호환되지 않아야 할 이유가 없더라도 이전 버전과 호환되지 않았 음을 의미합니다.
또한 처음에는 저장소를 SHA-1로 초기화하고 싶지 않습니다. 즉, 빈 저장소를 복제하는 경우 GIT_DEFAULT_HASH변수를 인식 하지 못하고 결국 SHA-1 저장소로 끝나기 때문입니다. SHA-256 저장소.

둘 다 매력적이지 않으므로 이와 같이 재 초기화하는 경우 저장소 초기화 코드에 알리고 SHA-1을 사용하는 경우 확장을 지우도록합시다.
이를 통해 유효하고 기능적인 저장소를 생성하고 다른 사용 사례를 위반하지 않습니다.