Release dan Tags

Pengguna tidak membaca riwayat commit — mereka mengunduh versi. Kegiatan sehari-hari kita berputar di commit dan pull request, tetapi momen publik sebuah proyek adalah rilisan: v1.0.0 yang diumumkan, dicatat perubahannya, dan diunduh ribuan kali tanpa perlu meng-clone apa pun. Semua itu berdiri di atas konsep yang sudah kita kuasai di section Tags dan Releases : tag annotated sebagai penanda titik rilis. Yang belum dibahas adalah lapisan platformnya — bagaimana tag berubah menjadi halaman rilis berisi catatan dan artefak yang siap dibagikan. Chapter ini melengkapi alurnya, lalu menguji nyata satu perintah yang bekerja di komputer kita: mengemas isi tag menjadi berkas distribusi.

Tag adalah Titik, Release adalah Kemasan #

Perbedaan keduanya paling mudah dipahami sebagai dua lapisan yang menumpuk:

Tag tetap menjadi fondasinya: sebuah release selalu menempel pada satu tag. Platform hanya menambahkan kemasan di sekelilingnya — mulai dari judul yang manusiawi sampai berkas biner yang tidak akan pernah masuk ke repository. Tag annotated, bukan lightweight, adalah pilihan yang tepat untuk fondasi ini; alasan lengkapnya (identitas tagger hingga ruang tanda tangan) sudah dibedah di Annotated Tag .

Alur Rilis di Platform #

Urutan lengkap dari meja kerja sampai halaman rilis terbit:

Dua nomor pertama mengikuti disiplin alur rilis yang sudah kita jalankan utuh di Release Workflow — termasuk konvensi prefiks v pada nama tag yang berpasangan dengan Semantic Versioning . Langkah ketiga membutuhkan ketelitian: git push biasa tidak membawa tag, perilaku yang dibuktikan di Berbagi Tag ke Remote .

Demo Nyata: Dorong Tag, Kemas Artefak #

Sandbox menyusun panggung yang sama dengan platform: repository kerja berisi dua commit, dan bare repo toko-pusat.git sebagai sisi server. Setelah tag v1.0.0 dibuat dengan git tag -a v1.0.0 -m "Rilis pertama", tag itu dikirim eksplisit:

git push origin v1.0.0

Output yang Dihasilkan:

To ../toko-pusat.git
 * [new tag]         v1.0.0 -> v1.0.0

Baris * [new tag] mengonfirmasi tag sampai ke server — dari titik ini platform dapat menawarkannya sebagai kandidat rilis. Kini bagian yang bisa kita kerjakan sepenuhnya di terminal: mengemas isi tag menjadi berkas distribusi.

git archive --format=tar.gz --output=v1.0.0.tar.gz v1.0.0

Perintah itu sunyi; hasilnya berkas v1.0.0.tar.gz di direktori kerja. Tiga argumennya: --format=tar.gz memilih format arsip terkompresi gzip, --output menentukan nama berkas hasil, dan v1.0.0 — sumber isinya — adalah tag yang barusan terdorong. Yang dikemas bukan isi direktori kerja, melainkan snapshot persis pada commit yang ditunjuk tag: keadaan repository pada momen rilis, terkunci, tak terpengaruh berkas lain yang kebetulan berseliweran.

Keberadaan dan ukuran berkasnya terbaca dengan ls:

ls -l v1.0.0.tar.gz

Output yang Dihasilkan:

-rw-rw-r-- 1 z z 251 Oct 13 13:33 v1.0.0.tar.gz

Nilai izin, nama pengguna, waktu, dan ukurannya menyesuaikan mesin dan isi repository — 251 byte adalah ukuran snapshot kecil milik sandbox. Isi arsip diperiksa tanpa mengekstraknya; tar -t mencantumkan anggota arsip, dan -z menandai bahwa arsip terkompresi gzip:

tar -tzf v1.0.0.tar.gz

Output yang Dihasilkan:

produk.md
situs.md

Dua berkas — persis isi repository pada commit bertag v1.0.0, lengkap dengan nama barunya (produk.md), dan diurutkan menurut nama. Opsi lain milik git archive — format zip, prefiks direktori --prefix, hingga subpohon tertentu — terdokumentasi di dokumentasi git archive .

Satu kejutan kecil menanti bila git status dijalankan sebelum arsip dibuang:

git status

Output yang Dihasilkan:

On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	v1.0.0.tar.gz

nothing added to commit but untracked files present (use "git add" to track)

Halaman Releases di Platform #

Dengan tag di server dan artefak di tangan, langkah keempat tabel berpindah ke web. Halaman Releases pada repository (GitHub dan GitLab; Bitbucket menempatkannya di tab Downloads) mendaftar seluruh tag yang telah dikemas. Membuat release baru berarti memilih tag — sudah ada atau dibuat saat itu juga — lalu mengisi kemasannya: judul (biasanya nama tagnya), catatan rilis, dan lampiran.

Perilaku platform yang paling membantu di halaman ini:

• Catatan rilis otomatis. Tombol penyusun catatan (mis. Generate release notes) memeriksa pull request yang masuk rentang antara tag sebelumnya dan tag ini, lalu menyusun daftar judulnya lengkap dengan nomor dan penulisnya — titik temu alami dari alur Fork dan Pull Request . Hasilnya bisa disunting bebas sebelum terbit; menyusun manual dari git log tetap menjadi jalur penuh kendali yang dibedah di Changelog .
• Lampiran biner. Berkas hasil git archive — atau installer, paket, image — diunggah langsung ke halaman release, tersimpan di platform, bukan di repository Git.
• Arsip sumber otomatis. Platform menyediakan tautan unduhan kode sumber (zip dan tar.gz) untuk setiap tag tanpa perintah tambahan — keluaran git archive kita di sandbox adalah versi lokal dari arsip yang sama.
• Status rilis. Tanda pre-release untuk kandidat uji coba, draft untuk yang belum terbit, dan latest untuk rilis terbaru yang ditautkan paling menonjol.

Momen publik proyek kini tertangani: tag menandai titiknya, git archive dan platform mengemas isinya, halaman release mengumumkannya. Satu pertanyaan penutup section ini justru menoleh ke belakang: dari semua yang kita pelajari — dua belas chapter tentang tiga platform — mana yang sebenarnya milik Git, dan mana yang akan tertinggal bila besok pindah platform? Pertanyaan itulah yang dijawab chapter terakhir.