Annotated Tag

Lightweight tag terbukti cuma penunjuk telanjang: git show-nya langsung membuka isi commit tanpa perkenalan. Untuk penanda pribadi itu cukup, tetapi rilis publik menuntut lebih — pengguna yang mengunduh v1.0.0 berhak tahu siapa yang membuat tag, kapan, dan apa maknanya. Git menjawab dengan annotated tag: jenis tag yang disimpan sebagai objek penuh di database, lengkap dengan identitas pembuat, tanggal, dan pesan. Chapter ini membedah objek tersebut sampai ke byte-nya, lalu mencoba memverifikasinya dan menemukan satu kejujuran penting tentang tanda tangan.

Membuat Annotated Tag #

Perbedaan perintahnya hanya dua karakter: opsi -a (annotate) dan pesan -m:

mkdir latihan-annotasi && cd latihan-annotasi
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf '# Toko Berkah\nberanda\n' > situs.md
git add situs.md
git commit -m "Buat beranda toko"
printf 'daftar produk unggulan\n' > katalog.md
git add katalog.md
git commit -m "Tambah halaman katalog"
git tag -a v1.0.0 -m "Rilis pertama"

Perintah tag tetap sunyi. Nama v1.0.0 kini muncul di daftar seperti biasa:

git tag

Output yang Dihasilkan:

v1.0.0

Yang berbeda justru di bawahnya. git show v1.0.0 tidak lagi langsung membuka commit:

git show v1.0.0

Output yang Dihasilkan:

tag v1.0.0
Tagger: Budi Santoso <[email protected]>
Date:   Sun Oct 25 11:15:00 2026 +0700

Rilis pertama

commit 8e39f42283810a0a1800c82c058c4dd36b476996
Author: Budi Santoso <[email protected]>
Date:   Sun Oct 25 11:10:00 2026 +0700

    Tambah halaman katalog

diff --git a/katalog.md b/katalog.md
new file mode 100644
index 0000000..eacf6d4
--- /dev/null
+++ b/katalog.md
@@ -0,0 +1 @@
+daftar produk unggulan

Enam baris pertama adalah kepala tag: tag v1.0.0, pembuatnya (Tagger), tanggal pembuatan tag, lalu pesan “Rilis pertama”. Baris commit 8e39f42 beserta isinya menyusul setelahnya — keluaran dua objek sekaligus. Bandingkan dengan keluaran git show pada lightweight tag di chapter sebelumnya yang langsung dimulai dari commit: annotated tag punya identitas sendiri sebelum menyerahkan isi commit.

Objek Tag yang Berdiri Sendiri #

Kepala itu bukan sulap format keluaran — memang ada objek tersendiri di database. git cat-file -t menanyakan jenis objek yang ditunjuk nama v1.0.0:

git cat-file -t v1.0.0

Output yang Dihasilkan:

tag

Jawabannya tag — bukan commit seperti pada lightweight tag. Isi objek itu kita baca utuh dengan git cat-file -p:

git cat-file -p v1.0.0

Output yang Dihasilkan:

object 8e39f42283810a0a1800c82c058c4dd36b476996
type commit
tag v1.0.0
tagger Budi Santoso <[email protected]> 1792901700 +0700

Rilis pertama

Lima baris itu adalah seluruh isi objek tag. object 8e39f42 mencatat commit yang ditunjuk — sama dengan commit “Tambah halaman katalog”. type commit menyatakan jenis objek sasaran. tag v1.0.0 memuat nama tag itu sendiri. Baris tagger merekam siapa pembuatnya dan kapan — lengkap dengan identitas serta stempel waktu. Baris terakhir adalah pesan “Rilis pertama” yang kita tulis lewat -m. Semua metadata yang absen pada lightweight tag tersimpan permanen di sini.

Penunjukan dua lapis ini terlihat pula pada hash. git rev-parse v1.0.0 melaporkan hash objek tag, bukan hash commit:

git rev-parse v1.0.0

Output yang Dihasilkan:

967229f921489ce56f26d392a38d47cce3bc41d7

Sedangkan hash commit di bawahnya bisa diambil dengan akhiran ^{commit} yang “mengupas” tag sampai ke commitnya:

git rev-parse "v1.0.0^{commit}"

Output yang Dihasilkan:

8e39f42283810a0a1800c82c058c4dd36b476996

Berkas ref fisiknya mengonfirmasi arah penunjukan itu:

cat .git/refs/tags/v1.0.0

Output yang Dihasilkan:

967229f921489ce56f26d392a38d47cce3bc41d7

Berkas refs/tags/v1.0.0 berisi 967229f — hash objek tag — yang di dalamnya barulah tersimpan hash commit 8e39f42. Hash-hash ini dihitung dari isi objek sehingga berbeda di mesin pembaca; pola dua lapisnya yang penting. Bandingkan dengan lightweight tag di chapter sebelumnya: berkas ref-nya langsung berisi hash commit.

Mencoba Verifikasi dan Menemukan Galat #

Objek tag menyediakan satu bidang lagi yang belum kita lihat: ruang untuk tanda tangan. Perintah git tag -v (verify) memeriksa tag dan memverifikasi tanda tangannya bila ada:

git tag -v v1.0.0

Output yang Dihasilkan:

object 8e39f42283810a0a1800c82c058c4dd36b476996
type commit
tag v1.0.0
tagger Budi Santoso <[email protected]> 1792901700 +0700

Rilis pertama
error: no signature found

Keluaran berhenti dengan galat error: no signature found — perintah ini mengembalikan kode galat dan menolak melanjutkan. Galat itu jujur dan memang benar: tag v1.0.0 kita belum ditandatangani siapa pun, sehingga tidak ada tanda tangan untuk diverifikasi. Isi tag tetap tercetak — objeknya sah — hanya verifikasi keaslian yang tidak bisa dilakukan. Untuk itu, tag harus dibuat dengan git tag -s menggunakan kunci GPG milik pembuatnya; mekanisme lengkapnya menjadi pokok chapter Menandatangani Commit dan Tag .

Lightweight atau Annotated #

Dua jenis itu kini punya wajah lengkap. Perbandingannya:

Dokumentasi resmi Git menyarankan annotated tag untuk semua keperluan serius; rinciannya terbaca di git-tag .

Kapan wajib annotated? Setiap kali tag akan dibagikan atau bertahan lama: rilis publik, titik rilis internal yang dirujuk tim, penanda milestone proyek. Metadata tagger menjawab pertanggungjawaban — siapa yang memutuskan “inilah v1.0.0” — dan pesan tag menjadi tempat catatan rilis singkat. Ruang tanda tangan menambah jaminan bahwa keputusan itu benar-benar lahir dari orang yang berhak. Lightweight tag tetap sah untuk penanda pribadi yang cepat dibuat dan cepat dibuang.

Membuat tag annotated hanyalah separuh pekerjaan — tag sebaik apa pun perlu dikelola: dipindah, diperbaiki, dihapus, dan diperiksa posisinya. Operasi-operasi itu, termasuk satu perintah yang sanggup menimpa tag yang sudah ada, dibahas di chapter berikutnya: Membuat dan Menghapus Tag .