Bagaimana cara menemukan hash cabang di Git?

Diberikan nama cabang lokal / jarak jauh, bagaimana saya bisa mendapatkan hash dari komit yang ditunjuk oleh cabang ini?

Perintahnya git rev-parseadalah temanmu, misal:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... atau untuk cabang pelacakan jarak jauh:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

Perintah ini umumnya sangat berguna, karena dapat mengurai salah satu cara dalam menentukan nama cabang git, seperti:

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

... dll.

Hash disimpan di bawah .git/refs/, misalnya.git/refs/heads/master

Tetapi gunakan git rev-parsesecara terprogram seperti yang disarankan oleh Mark Longair karena lebih aman.

Jangan lupa bahwa sejak Git 2.19 (Q2 2018), Git mempersiapkan transisi dari hash SHA1 ke SHA2: lihat " Mengapa Git tidak menggunakan SHA yang lebih modern? "

Dengan Git 2.25 (Q1 2020), git rev-parse berkembang dan mencerminkan kemungkinan hash baru itu.

Lihat commit fa26d5e , commit cf02be8 , commit 38ee26b , commit 37ab8eb , commit 0370b35 , commit 0253e12 , commit 45e2ef2 , commit 79b0edc , commit 840624f , commit 32a6707 , komit 440bf91 , komit 0b408ca , komit 2eabd38 (28 Oktober 2019), dan komit 1bcef51 , komit ecde49b (05 Okt 2019) oleh brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit 28014c1, 10 Nov 2019)}

rev-parse: tambahkan --show-object-formatopsi

^{Ditandatangani oleh: brian m. carlson}

Tambahkan opsi untuk mencetak format objek yang digunakan untuk input, output, atau penyimpanan.
Ini memungkinkan skrip shell menemukan algoritma hash yang digunakan.

Karena rencana transisi memungkinkan beberapa algoritma input, dokumen yang kami berikan dapat memberikan banyak hasil untuk input, dan format yang mungkin diambil oleh hasil.
Meskipun kami tidak mendukung ini sekarang, mendokumentasikannya lebih awal berarti bahwa penulis skrip dapat membuktikan skrip mereka di masa depan ketika kami melakukannya.

The git rev-parseDokumentasi sekarang termasuk:

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

Menampilkan format objek (algoritme hash) yang digunakan untuk repositori untuk penyimpanan di dalam .gitdirektori, input, atau output. Untuk input, beberapa algoritma dapat dicetak, dipisahkan spasi. Jika tidak ditentukan, defaultnya adalah "penyimpanan".

Dengan Git 2.29 (Q4 2020), Anda dapat memastikan format apa yang harus Anda gunakan untuk membaca komit hash dari cabang (atau objek lain).

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

docs: tambahkan dokumentasi untuk extensions.objectFormat

^{Ditandatangani oleh: brian m. carlson
Diulas-oleh: Eric Sunshine}

Dokumentasikan extensions.objectFormatpengaturan konfigurasi.
Peringatkan pengguna untuk tidak mengubahnya sendiri.

git configsekarang termasuk di halaman manualnya :

extensions.objectFormat

Tentukan algoritma hash yang akan digunakan.

Nilai yang dapat diterima adalah sha1dan> sha256.
Jika tidak ditentukan, sha1diasumsikan.
Ini adalah kesalahan untuk menentukan kunci ini kecuali core.repositoryFormatVersion1.

Perhatikan bahwa setelan ini hanya boleh disetel oleh git initatau git clone.
Mencoba mengubahnya setelah inisialisasi tidak akan berhasil dan akan menghasilkan masalah yang sulit didiagnosis.

Untuk memperjelas, dengan Git 2.29 (Q4 2020), penambahan dukungan SHA-256 baru-baru ini ditandai sebagai eksperimental dalam dokumentasi.

Lihat commit ff233d8 (16 Agustus 2020) oleh Martin Ågren ( none) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit d1ff741 , 24 Agustus 2020)}

Documentation: tandai --object-format=sha256sebagai percobaan

^{Ditandatangani oleh: Martin Ågren}

Setelah eff45daab8 (" repository: aktifkan dukungan SHA-256 secara default", 2020-07-29, Git v2.29.0 - merge terdaftar di batch # 6 ), build vanilla dari Git memungkinkan pengguna untuk menjalankan, misalnya,

git init --object-format=sha256  

dan meretas.
Ini bisa menjadi cara yang baik untuk mendapatkan pengalaman dengan dunia SHA-256, misalnya, untuk menemukan bug itu

GIT_TEST_DEFAULT_HASH=sha256 make test  

tidak melihat.

Tapi ini benar-benar dunia yang terpisah: Repo SHA-256 seperti itu akan hidup sepenuhnya terpisah dari (sekarang cukup besar) set repo SHA-1.
Berinteraksi melintasi perbatasan pada prinsipnya dimungkinkan, misalnya, melalui " diff+apply " (atau " format-patch+ am"), tetapi bahkan itu memiliki batasannya: Menerapkan perbedaan SHA-256 dalam repo SHA-1 berfungsi dalam kasus sederhana, tetapi jika Anda harus menggunakan -3, Anda kurang beruntung.

Demikian pula, " push+pull " seharusnya berfungsi, tetapi Anda benar-benar akan mengoperasikan sebagian besar pengimbangan dari negara lain. Itu mungkin baik-baik saja pada saat Anda menginisialisasi repositori Anda, dan mungkin akan baik-baik saja selama beberapa bulan setelah itu, tetapi mungkin akan datang suatu hari ketika Anda mulai menyesali penggunaan [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> dan memiliki gali diri Anda ke dalam lubang yang cukup dalam.

Saat ini ada topik untuk mendokumentasikan format data dan protokol kami terkait SHA-256 dan dalam beberapa kasus (midx dan commit-graph), kami mempertimbangkan untuk menyesuaikan bagaimana format file menunjukkan format objek mana yang akan digunakan.

Dimanapun --object-formatdisebutkan dalam dokumentasi kita, mari kita perjelas bahwa menggunakannya dengan "sha256" adalah percobaan.
Jika nanti kami perlu menjelaskan mengapa kami tidak dapat menangani data yang kami buat pada tahun 2020, kami selalu dapat menunjukkan paragraf yang kami tambahkan di sini.

Dengan "include ::" - membuat uraian kecil, kita harus dapat konsisten di seluruh dokumentasi dan pada akhirnya dapat mengurangi tingkat keparahan teks ini secara bertahap.
Suatu hari, kita bahkan mungkin menggunakannya untuk mulai menghapus secara bertahap --object-format=sha1, tetapi jangan terlalu terburu-buru ...

Ada juga extensions.objectFormat, tapi hanya disebutkan tiga kali. Dua kali kami menambahkan pelepasan tanggung jawab hukum baru ini dan di tempat ketiga kami sudah memiliki peringatan "jangan edit". Dari sana, pembaca yang tertarik pada akhirnya akan menemukan yang baru ini yang kami tambahkan di sini.

Karena GIT_DEFAULT_HASHmenyediakan titik masuk lain ke fungsi ini, dokumentasikan juga sifat eksperimentalnya.

gitsekarang termasuk di halaman manualnya :

digunakan sebagai gantinya. Standarnya adalah "sha1". VARIABEL INI ADALAH EKSPERIMENTAL! Lihat --object-formatdi git init.

object-format-disclaimersekarang termasuk di halaman manualnya :

OPSI INI ADALAH EKSPERIMENTAL!
Dukungan SHA-256 masih eksperimental dan masih dalam tahap awal.

Repositori SHA-256 secara umum tidak akan dapat> berbagi pekerjaan dengan repositori SHA-1 "biasa".
Harus diasumsikan bahwa, misalnya, format file internal Git dalam kaitannya dengan repositori SHA-256 dapat berubah dengan cara yang tidak kompatibel dengan versi sebelumnya.
Gunakan hanya --object-format=sha256untuk tujuan pengujian.

Git 2.29 (Kuartal 4 2020) yang sama memastikan bahwa " git clone" ^{( man )} akan berfungsi saat satu klon dari repositori SHA-1, sementara GIT_DEFAULT_HASHdisetel untuk menggunakan SHA-256.
Sebelum 2.29, itu menghasilkan repositori yang tidak dapat digunakan yang setengahnya mengklaim sebagai repositori SHA-256 dengan objek dan referensi SHA-1.
Ini telah diperbaiki.

Lihat commit 47ac970 (20 Sep 2020) oleh brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- di commit b28919c , 29 Sep 2020)}

builtin/clone: hindari kegagalan dengan GIT_DEFAULT_HASH

^{Dilaporkan oleh: Matheus Tavares
Ditandatangani oleh: brian m. carlson}

Jika pengguna mengkloning repositori SHA-1 dengan GIT_DEFAULT_HASHset ke " sha256", maka kita bisa berakhir dengan repositori di mana versi format repositori adalah 0 tetapi extensions.objectformatkuncinya disetel ke " sha256".
Ini salah (pengguna memiliki repositori SHA-1) dan nonfungsional (karena ekstensi tidak dapat digunakan dalam repositori v0).

Ini terjadi karena dalam sebuah klon, kami awalnya menyiapkan repositori, lalu mengubah algoritmanya berdasarkan apa yang dikatakan sisi jarak jauh yang digunakannya.
Kami awalnya telah menyiapkan repositori sebagai SHA-256 dalam kasus ini, dan kemudian menyetel ulang versi repositori tanpa menghapus ekstensi.

Kami selalu dapat menetapkan ekstensi dalam kasus ini, tetapi itu berarti repositori SHA-1 kami tidak kompatibel dengan versi Git yang lebih lama, meskipun tidak ada alasan mengapa tidak demikian.
Dan kami juga tidak ingin menginisialisasi repositori sebagai SHA-1 pada awalnya, karena itu berarti jika kami mengkloning repositori kosong, kami akan gagal menerima GIT_DEFAULT_HASHvariabel dan akan berakhir dengan repositori SHA-1, bukan repositori SHA-256.

Tidak ada yang menarik, jadi beri tahu kode inisialisasi repositori jika kita melakukan pengulangan seperti ini, dan jika demikian, untuk menghapus ekstensi jika kita menggunakan SHA-1.
Ini memastikan kami menghasilkan repositori yang valid dan fungsional dan tidak merusak kasus penggunaan kami yang lain.