Kita sudah paham bahwa tag adalah penunjuk tetap. Sekarang waktunya membuatnya sendiri — mulai dari jenis paling sederhana: lightweight tag, tag yang dibuat tanpa opsi apa pun dan isinya benar-benar cuma penunjuk ke satu commit. Jenis ini cepat dibuat dan pas untuk kebutuhan pribadi. Chapter ini mengetes perilakunya di repository latihan: membuat tag di posisi saat ini, menempatkannya di commit lama, menyaring daftar tag dengan pola, lalu membedah isi tag ini untuk melihat apa yang tidak dimilikinya.

Membuat Tag di Commit Saat Ini #

Repository latihan berisi empat commit perjalanan situs toko:

bash 
mkdir latihan-ringan && cd latihan-ringan
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 halaman beranda"
printf 'tentang toko berkah\n' > tentang.md
git add tentang.md
git commit -m "Tambah halaman tentang"
printf '# Toko Berkah\nBeranda\n' > situs.md
git add situs.md
git commit -m "Perbaiki judul beranda"
printf '[email protected]\n' > kontak.md
git add kontak.md
git commit -m "Tambah halaman kontak"
git tag v0.1.0

Seperti di chapter sebelumnya, git tag v0.1.0 sunyi — tidak ada keluaran. Buktinya dilihat lewat daftar tag:

bash 
git tag

Output yang Dihasilkan:

text 
v0.1.0

Tag v0.1.0 kini menunjuk commit terakhir, “Tambah halaman kontak”. Inilah perilaku default: tanpa argumen commit, tag dibuat pada HEAD.

Menempatkan Tag di Commit Lain #

Kita juga bisa menandai titik di masa lalu dengan memberikan hash sebagai argumen tambahan. Misalnya commit “Tambah halaman tentang” adalah titik yang ingin kita ingat:

bash 
git tag v0.0.9 cfad0f5

Argumen kedua boleh hash lengkap maupun pendek, juga nama ref seperti HEAD~2 atau branch. Daftar tag kini bertambah:

bash 
git tag

Output yang Dihasilkan:

text 
v0.0.9
v0.1.0

v0.0.9 sengaja kita nomori lebih rendah — penanda bahwa commit itu lebih lama daripada v0.1.0. Git sendiri tidak peduli aturan penamaan; angka versi bermakna murni konvensi yang dibahas di Semantic Versioning .

Menyaring Daftar Tag dengan Pola #

Bila tag sudah banyak, git tag yang mencetak semuanya menjadi berisik. Opsi -l (list) menerima pola glob untuk menyaring:

bash 
git tag -l "v0.1.*"

Output yang Dihasilkan:

text 
v0.1.0

Pola "v0.1.*" hanya cocok dengan v0.1.0 — v0.0.9 tersaring keluar. Pola yang tidak cocok dengan tag mana pun tidak menghasilkan keluaran sama sekali; git tag -l "v1.*" pada repository ini sunyi karena belum ada satu pun tag v1. Perilaku sunyi ini penting diingat: tidak ada baris berarti tidak ada kecocokan, bukan perintah gagal.

Membedah Isi Lightweight Tag #

Apa sebenarnya yang dimiliki v0.1.0? Kita buka dari tiga sisi. Pertama, git show menampilkan objek yang ditunjuk:

bash 
git show v0.1.0

Output yang Dihasilkan:

text 
commit ae9ffef08475849d1e4625d88b10fcfc6c871718
Author: Budi Santoso <[email protected]>
Date:   Sun Oct 25 10:20:00 2026 +0700

    Tambah halaman kontak

diff --git a/kontak.md b/kontak.md
new file mode 100644
index 0000000..fc4a6d8
--- /dev/null
+++ b/kontak.md
@@ -0,0 +1 @@
[email protected]

Perhatikan baik-baik: keluaran langsung membuka dengan commit ae9ffef — tidak ada kepala tag, tidak ada nama pembuat tag, tidak ada tanggal pembuatan tag. Yang tampil hanyalah isi commit itu sendiri: penulis, tanggal commit, pesan, dan diff. Kedua, kita tanyakan jenis objeknya:

bash 
git cat-file -t v0.1.0

Output yang Dihasilkan:

text 
commit

Git menjawab commit — nama v0.1.0 memang menunjuk langsung objek commit, bukan objek lain. Ketiga, kita baca berkas ref fisiknya:

bash 
cat .git/refs/tags/v0.1.0

Output yang Dihasilkan:

text 
ae9ffef08475849d1e4625d88b10fcfc6c871718

Isinya hash commit ae9ffef — sama persis dengan yang dilaporkan git rev-parse v0.1.0:

bash 
git rev-parse v0.1.0

Output yang Dihasilkan:

text 
ae9ffef08475849d1e4625d88b10fcfc6c871718

Rangkaian bukti itu menegaskan definisi lightweight tag: satu berkas ref berisi satu hash commit, tanpa objek tambahan. Konsekuensinya jelas — tidak ada tempat menyimpan siapa pembuatnya, kapan dibuat, atau mengapa tag itu diberi nama. Untuk penanda pribadi hal itu tidak masalah; kita tahu sendiri konteksnya.

Keadaan akhir repository terlihat rapi dengan kedua tag di tempatnya:

bash 
git log --oneline --decorate

Output yang Dihasilkan:

text 
ae9ffef (HEAD -> main, tag: v0.1.0) Tambah halaman kontak
80458be Perbaiki judul beranda
cfad0f5 (tag: v0.0.9) Tambah halaman tentang
e4984b8 Buat halaman beranda

Kapan Lightweight Tag Cukup #

Karena tanpa metadata, lightweight tag cocok untuk kebutuhan yang sifatnya pribadi dan sementara:

  • penanda pribadi seperti eksperimen-query-lancar untuk keperluan navigasi sendiri;
  • titik sementara selama penyelidikan bug — dibuat cepat, dihapus saat selesai;
  • penanda lokal yang tidak pernah dibagikan ke orang lain.

Sebaliknya, begitu tag akan dibagikan ke publik atau bertahan lama, kelemahan itu berubah jadi masalah: pembaca tag tidak bisa tahu siapa pembuatnya, kapan dibuat, dan apa makna v0.1.0 itu. Git menyediakan jenis kedua yang menjawab kebutuhan itu — annotated tag, objek tag tersendiri dengan pesan, penanda waktu, dan identitas pembuat yang tersimpan penuh di database. Perilakunya cukup berbeda sehingga layak dibedah satu chapter penuh: Annotated Tag .