Commit Hash dan References

Sepanjang section ini kita menyebut commit dengan bermacam nama tanpa mempersoalkannya: HEAD di git cat-file -p HEAD, nama branch di git log main, singkatan tujuh karakter di git log --oneline, sampai HEAD~1 di chapter Anatomi Commit . Semua nama itu menunjuk objek yang sama di satu waktu — dan sebenarnya selalu berujung pada satu bentuk: hash 40 karakter. Chapter ini membedah bentuk itu, aturan singkatannya, lalu memperkenalkan git rev-parse sebagai penerjemah resmi dari semua nama menjadi hash.

Hash SHA-1: 40 Karakter Heksadesimal #

Kita pakai repository kecil dengan satu merge — pola yang sudah akrab dari chapter Graph History :

mkdir latihan-refs && cd latihan-refs
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf 'Catatan 1: perkenalan proyek\n' > catatan.txt
git add catatan.txt
git commit -m "Tambah catatan proyek"
printf '1. rancang struktur\n2. tulis panduan\n' > tugas.txt
git add tugas.txt
git commit -m "Tambah daftar tugas"
git tag v1.0
git switch -c fitur
printf '1. rancang struktur\n2. tulis panduan\n3. uji tampilan\n' > tugas.txt
git add tugas.txt
git -c user.name="Siti Rahma" -c user.email="[email protected]" \
  commit -m "Tambah tugas validasi tampilan"
git switch main
printf 'Catatan 1: perkenalan proyek\nCatatan 2: rilis internal\n' > catatan.txt
git add catatan.txt
git commit -m "Tambah catatan rilis internal"
git merge fitur -m "Merge branch 'fitur'"

Bentuk riwayatnya — satu merge dengan dua sisi:

git log --oneline --graph

Output yang Dihasilkan:

*   ab63b04 Merge branch 'fitur'
|\  
| * 81e66bf Tambah tugas validasi tampilan
* | b662f3e Tambah catatan rilis internal
|/  
* cdb6d4f Tambah daftar tugas
* c368056 Tambah catatan proyek

Perintah git rev-parse <nama> mengevaluasi nama apa pun menjadi hash objeknya. Untuk HEAD:

git rev-parse HEAD

Output yang Dihasilkan:

ab63b047479ab0a80818b83efded82ba8c61d796

Empat puluh karakter itu adalah bentuk penuh identitas commit: hash SHA-1 atas seluruh isi objek. Karakternya berasal dari sistem bilangan basis enam belas — himpunan 0123456789abcdef — sehingga tiap posisi menyimpan empat bit dan 40 karakter menyimpan 160 bit. Jumlah nilai yang mungkin mencapai 2 pangkat 160; itulah ruang yang membuat dua commit berbeda hampir mustahil berhash sama. Karena hash dihitung dari isi, hash sekaligus menjadi alamat penyimpanan objek — tema chapter Anatomi Commit .

Nama branch dan nama tag adalah label yang menempel pada hash. main saat ini berada tepat di HEAD:

git rev-parse main

Output yang Dihasilkan:

ab63b047479ab0a80818b83efded82ba8c61d796

Sementara tag v1.0 yang kita tempel sebelum percabangan menunjuk commit yang lebih tua:

git rev-parse v1.0

Output yang Dihasilkan:

cdb6d4f142f5f3f9a39b1ac36cfd146dffcc6d9c

Singkatan Hash dan Panjang Minimal #

Empat puluh karakter terlalu boros untuk diketik, dan Git menyediakan singkatan yang aman:

git rev-parse --short HEAD

Output yang Dihasilkan:

ab63b04

Tujuh karakter — panjang bawaan git log --oneline — praktis selalu cukup: peluang dua commit berawalan sama tujuh karakter nyaris nol. Panjang itu bisa diatur turun dengan --abbrev:

git log --oneline --abbrev=4

Output yang Dihasilkan:

ab63 Merge branch 'fitur'
b662 Tambah catatan rilis internal
81e6 Tambah tugas validasi tampilan
cdb6 Tambah daftar tugas
c368 Tambah catatan proyek

Empat karakter ternyata masih unik di repository ini. Nilai --abbrev=<n> berperan sebagai batas minimal, bukan panjang pasti — Git menjamin singkatan tetap menunjuk satu objek saja dengan memperpanjangnya otomatis bila perlu. Bukti nyatanya muncul saat kita meminta satu karakter:

git log --oneline --abbrev=1

Output yang Dihasilkan:

ab63 Merge branch 'fitur'
b662 Tambah catatan rilis internal
81e6 Tambah tugas validasi tampilan
cdb6 Tambah daftar tugas
c368 Tambah catatan proyek

Keluarannya tetap empat karakter: ruang satu karakter terlalu sempit untuk membedakan cdb6d4f dari c368056 (keduanya berawalan c), dan Git memperpanjang sampai singkatan menjadi unik di dalam repository. Pada repository raksasa berisi jutaan objek, bawaan tujuh karakter pun bisa otomatis naik delapan atau lebih — kelakuan yang sama, tanpa perintah tambahan.

rev-parse: Penerjemah Nama ke Hash #

Kekuatan rev-parse bukan sekadar membuka satu nama, melainkan menerima hampir semua kosakata penunjuk commit sekaligus. Empat nama berbeda dievaluasi dalam satu perintah:

git rev-parse HEAD~1 HEAD^ HEAD^2 main^2

Output yang Dihasilkan:

b662f3ed7b93e01bd356f30db69b20107e0415e4
b662f3ed7b93e01bd356f30db69b20107e0415e4
81e66bfb17c3cfbade5e4768b26d1889b6a977c8
81e66bfb17c3cfbade5e4768b26d1889b6a977c8

Baris pertama dan kedua identik: HEAD~1 dan HEAD^ sama-sama menunjuk parent pertama dari merge — commit b662f3e di sisi main. Baris ketiga dan keempat juga identik: HEAD^2 dan main^2 sama-sama menunjuk parent kedua — commit 81e66bf di sisi fitur. Pemetaan lengkap kosakata tersebut pada repository kita:

Notasi ~ dan ^ di tabel di atas baru diperkenalkan sepintas — bedah penuh perbedaan keduanya, lengkap dengan relasi parent yang menjadi dasarnya, adalah pokok bahasan chapter Parent Commit .

Posisi Lama Sebuah Ref: ref@{n} #

Satu bentuk nama terakhir memakai data dari luar riwayat: HEAD@{n} membaca reflog, catatan pergerakan HEAD yang diperkenalkan di chapter Mencari Commit . Di repository kita, langkah terakhir HEAD sebelum merge adalah commit Tambah catatan rilis internal:

git rev-parse HEAD@{1}

Output yang Dihasilkan:

b662f3ed7b93e01bd356f30db69b20107e0415e4

Bacaannya: satu langkah lalu, HEAD berada di b662f3e — nilai yang sama dengan HEAD~1 pada repository ini karena HEAD@{1} kebetulan merekam posisi sebelum commit rilis dibuat. Kesamaan itu tidak berlaku umum: ~ menghitung dari struktur riwayat, sedangkan @{n} menghitung dari riwayat pergerakan — setelah git reset, amend, atau pindah-pindah branch, keduanya memberi jawaban berbeda. Reflog dan pemulihan commit lewat HEAD@{n} dibahas tuntas di chapter git reflog .

Kosakata lengkap sintaks penunjuk — termasuk rentang A..B dan A...B yang akan banyak terpakai di section Branch dan Merging — terdokumentasi di gitrevisions , sementara perilaku rev-parse dijabarkan di dokumentasi git rev-parse . Semua nama itu pada akhirnya mengevaluasi satu struktur yang sama: rantai parent antar commit. Struktur rantai itulah yang kita bedah di chapter berikutnya: Parent Commit .