Bagian 4: Tag dan Release

Riwayat main kini utuh: catatan berdiri, panduan dan glosarium menyusul lewat merge yang terlihat. Keadaan semacam ini layak diingat — dan cara Git mengingatnya adalah tag. Bagian penutup proyek menandai keadaan repository sebagai versi v1.0.0 melalui tiga langkah rilis: baris versi pada README.md, commit persiapan rilis, dan tag annotated yang menyimpan pesan serta pembuatnya. Di akhir bagian, git show dan git describe memverifikasi bahwa tanda itu tertanam tepat, lalu seluruh proyek dirangkum sebagai bekal menuju enam proyek berikutnya.

Menandai Versi pada README #

Pembaca repository perlu tahu versi apa yang sedang dipegangnya tanpa membuka riwayat. Satu baris di akhir README.md memenuhi kebutuhan itu:

cat > README.md <<'EOF'
# Buku Catatan

Kumpulan catatan belajar saya.

## Daftar Isi

- [Panduan Struktur Catatan](docs/panduan.md)
- [Glosarium Git](docs/glosarium.md)

Versi: v1.0.0
EOF

cat README.md

Output yang Dihasilkan:

# Buku Catatan

Kumpulan catatan belajar saya.

## Daftar Isi

- [Panduan Struktur Catatan](docs/panduan.md)
- [Glosarium Git](docs/glosarium.md)

Versi: v1.0.0

Angka 1.0.0 bukan pilihan acak. Semantic Versioning menetapkan MAJOR.MINOR.PATCH, dan 1.0.0 menandai keadaan pertama yang dianggap lengkap — bukti konsep masih 0.x.x, sedangkan 1.0.0 menyatakan “isi dasar sudah ada dan siap dipakai”. Aturan penomoran lengkapnya dibahas pada chapter Semantic Versioning .

Commit Persiapan Rilis #

Baris versi itu sendiri adalah satu keputusan, maka ia disimpan sebagai satu commit dengan tipe chore — pekerjaan penunjang yang bukan konten:

git add README.md
git commit -m "chore: siapkan rilis v1.0.0"

Output yang Dihasilkan (perintah terakhir):

[main bd9ad50] chore: siapkan rilis v1.0.0
 1 file changed, 2 insertions(+)

Membuat Tag Annotated v1.0.0 #

Sekarang tanda resminya. Tag yang tepat untuk rilis adalah tag annotated — objek penuh di database Git yang membawa nama pembuat, tanggal, dan pesan, berbeda dari lightweight tag yang hanya nama tempelan pada satu commit:

git tag -a v1.0.0 -m "Rilis pertama: catatan, panduan, dan glosarium"

Perintah git tag tidak menghasilkan keluaran — sunyi adalah tanda suksesnya. Daftar seluruh tag memastikan:

git tag

Output yang Dihasilkan:

v1.0.0

Isi lengkap tag tersebut — siapa pembuatnya, pesannya, dan ke commit mana ia menunjuk — terbaca lewat git show:

git show v1.0.0 --stat

Output yang Dihasilkan:

tag v1.0.0
Tagger: Budi Santoso <[email protected]>
Date:   Tue Oct 13 10:10:00 2026 +0700

Rilis pertama: catatan, panduan, dan glosarium

commit bd9ad50ba03974b25b5eed6b64513739eb0d8564
Author: Budi Santoso <[email protected]>
Date:   Tue Oct 13 10:00:00 2026 +0700

    chore: siapkan rilis v1.0.0

 README.md | 2 ++
 1 file changed, 2 insertions(+)

Keluaran tersebut tersusun dua lapis:

1. Blok pertama — objek tag itu sendiri: nama v1.0.0, tagger beserta emailnya, tanggal tag dibuat, lalu pesan rilisnya. Blok ini hanya ada pada tag annotated.
2. Blok kedua — commit yang ditunjuk: hash penuh bd9ad50..., penulis, tanggal commit, pesan commit, dan ringkasan --stat perubahannya.

Perbedaan annotated dan lightweight dibahas tuntas pada chapter Annotated Tag , dan seluruh opsi git tag terdokumentasi di dokumentasi resmi git tag .

Mengetahui Posisi dari Tag: git describe #

Satu pertanyaan sering muncul setelah rilis: “posisi commit saat ini berapa jauh dari rilis terakhir?” Perintah git describe menjawabnya dengan mencari tag terdekat di sekitar HEAD:

git describe --tags

Output yang Dihasilkan:

v1.0.0

Keluaran polos v1.0.0 berarti HEAD tepat berada di tag itu — tidak ada commit setelahnya. Begitu commit baru disimpan, keluarannya berubah bentuk menjadi misalnya v1.0.0-3-g5f2a1c3: tiga commit setelah tag, pada hash pendek 5f2a1c3. Format inilah yang dipakai banyak proyek untuk memberi nama build otomatis — lengkapnya di dokumentasi git describe .

Riwayat Akhir Proyek #

Rangkaian terakhir sebelum ringkasan — seluruh perjalanan dalam satu layar:

git log --oneline

Output yang Dihasilkan:

bd9ad50 chore: siapkan rilis v1.0.0
c444343 Merge branch 'fitur/tambah-glosarium'
68e553b docs: tambahkan glosarium istilah Git dasar
ecb3bec docs: lengkapi README dengan daftar isi
fd7e5b9 docs: tambahkan panduan struktur catatan
d047b69 chore: tambahkan .gitignore
6c59970 docs: rintis buku catatan

Tujuh baris, tujuh keputusan: dua pekerjaan penunjang, tiga penambahan konten, satu commit fitur, dan satu penyatuan. Tidak ada satu pun baris yang bertanya “apa yang barusan terjadi?” — itulah ukuran riwayat yang sehat untuk repository yang baru berumur satu proyek.

Ringkasan Proyek #

Pencapaian tiap bagian sekaligus perintah kuncanya:

Konsep yang dipraktikkan beserta tempat teorinya:

Setelah Proyek Ini #

Repository pribadi pertama kita selesai dengan struktur yang bisa dibanggakan: berkas terorganisir, riwayat terbaca, dan rilis tertandai. Namun alur kerja satu orang punya satu celah besar: setiap eksperimen berjalan sendirian tanpa ujian konflik. Proyek 02: Workflow Feature Branch menempatkan ritme branch yang baru dikuasai ke situasi yang lebih realistis — branch yang hidup lebih lama, perubahan yang bertabrakan, dan merge conflict yang harus diurai tangan. Semua bekalnya sudah di tangan; tinggal dibawa ke medan yang sedikit lebih kasar.