Tag & GitHub Releases: Menandai Versi
Membuat tag annotated vs lightweight, push tag, dan menerbitkan release di GitHub.
Kenapa butuh tag kalau sudah ada commit?
Hash commit seperti a3f9c1d itu akurat, tapi tidak manusiawi. Coba bayangkan kamu mau bilang ke teman: "download versi yang hash-nya a3f9c1d ya". Tidak ada yang hafal. Tag memberi nama yang bermakna dan gampang diingat: v1.0.0, v2.1-beta.
Tag ada karena "versi yang dirilis ke pengguna" adalah momen spesial yang harus bisa ditunjuk dengan jari. Branch bergerak maju, tapi tag menempel diam di satu commit. Enam bulan lagi kamu tetap bisa bilang "bug ini muncul sejak v1.2.0" dan semua orang tahu kode yang mana.
Ada dua jenis tag:
git tag v1.0.0 # lightweight: cuma pointer biasa
git tag -a v1.0.0 -m "Rilis pertama" # annotated: objek penuh + pesan + penandaPakai annotated untuk rilis resmi: ia menyimpan siapa penandanya, kapan, pesannya apa, dan bisa ditandatangani GPG. Lightweight cukup untuk penanda pribadi sementara, misalnya menandai commit buat dicoba nanti.
Contoh 1: membuat dan memeriksa tag
Buat tag annotated di commit terakhir:
git tag -a v1.0.0 -m "Rilis pertama: login dan dashboard"
git tagv1.0.0
v0.9-beta
Periksa detailnya:
git show v1.0.0tag v1.0.0
Tagger: OmniDev <[email protected]>
Date: Thu Oct 8 10:00:00 2026 +0700
Rilis pertama: login dan dashboard
commit e4f5a6b...
Tambah validasi form login
Lengkap: siapa, kapan, pesan apa, commit mana. Salah bikin tag lokal? Hapus dengan git tag -d v1.0.0-beta.
Contoh 2: push tag ke remote (jebakan klasik!)
Ini jebakan yang dialami hampir semua pemula: git push TIDAK mengirim tag! Kamu push, tag-nya tertinggal di laptop. Harus eksplisit:
git push origin v1.0.0Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 160 bytes | 160.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://github.com/kamu/repo.git
* [new tag] v1.0.0 -> v1.0.0
Baris [new tag] memastikan tag sampai di remote. Banyak tag? Kirim sekaligus:
git push origin --tagsGitHub Releases: bungkus tag jadi halaman rilis
Setelah tag ter-push, buka repo di GitHub > Releases > "Draft a new release", pilih tag v1.0.0, tulis catatan rilis (fitur baru, bug fix, breaking change), dan lampirkan file binary bila ada (.apk, .zip). Klik Publish: GitHub membuat halaman rilis cantik dengan link download.
Format penomoran versi yang populer adalah Semantic Versioning (MAJOR.MINOR.PATCH): naikkan MAJOR kalau ada perubahan breaking, MINOR untuk fitur baru yang tetap kompatibel, PATCH untuk bug fix. Jadi v1.0.1 itu hotfix kecil, v1.1.0 itu ada fitur baru, v2.0.0 itu ada yang berubah dan mungkin merusak kode lama.
Catatan teknis: tag menunjuk ke satu commit spesifik dan tidak pernah bergerak (berbeda dengan branch yang maju terus). Karena itu tag ideal untuk menandai "kode persis yang dirilis". Jangan pernah memindahkan tag yang sudah dipublikasikan; kalau salah, buat tag baru sebagai gantinya.
Kapan membuat tag?
Setiap kali ada rilis ke pengguna: v1.0.0 saat aplikasi pertama kali dipakai orang, v1.0.1 untuk hotfix darurat, v1.1.0 untuk fitur baru. Bahkan proyek tugas sekolah pun sebaiknya ditandai: dosen jauh lebih mudah menilai "v1.0 yang dikumpulkan" daripada disuruh menebak commit mana yang dimaksud.
Kesalahan umum pemula
SALAH: lupa push tag, lalu bingung kenapa tidak muncul di GitHub.
git tag v1.0.0
git push # tag-nya tidak ikut!BENAR: push tag secara eksplisit setiap kali.
git tag -a v1.0.0 -m "Rilis pertama"
git push origin v1.0.0 # jangan lupa baris iniKesalahan kedua: memindahkan tag yang sudah dipublikasikan karena "versi rilisnya salah commit". Orang yang sudah download v1.0.0 akan pegang kode beda dengan v1.0.0 yang baru. Solusinya selalu sama: buat tag baru (v1.0.1), jangan geser yang lama.
Tantangan
Rilis versi pertamamu
Di repo latihan: buat annotated tag v0.1.0 dengan pesan 'Rilis latihan pertama'. Push tag-nya ke GitHub (git push origin v0.1.0), lalu buat GitHub Release dari tag itu dengan catatan 2 baris. Kirim link release-nya sebagai bukti.