Rilis v1.2.0 di chapter sebelumnya berjalan mulus, tetapi ada satu pertanyaan yang belum terjawab tuntas: dari mana baris-baris CHANGELOG.md itu berasal? Menyalin git log mentah ke halaman rilis adalah jawaban yang salah — log berisi teknis (“Siapkan rilis v1.2.0”, merge, typo yang diubah), sedangkan pengguna bertanya hal yang jauh lebih sederhana: apa yang baru, apa yang berubah, apa yang diperbaiki. Changelog adalah dokumen terjemahan dari riwayat commit ke bahasa manusia. Chapter ini menyusunnya dari nol: menimbah draft dari git log, merapikannya ke format Keep a Changelog, lalu menautkan tiap versi ke perbandingan tag.

Draft Kasar dari Log #

Bahan mentah changelog memang riwayat — kita hanya perlu memilih rentangnya. Tag menjadi pagar alami: commit sejak v1.1.0 hingga v1.2.0 adalah isi rilis terbaru. Repository latihan-rilis dari chapter sebelumnya masih memegang jawabannya:

bash 
cd latihan-rilis
git log v1.1.0..v1.2.0 --oneline

Output yang Dihasilkan:

text 
e910f52 Siapkan rilis v1.2.0
d18d4e5 Perbaiki tautan rusak di beranda
f88f6b9 Tambah kolom pencarian produk

Tiga baris itu draft mentah kita. Rentang dua titik v1.1.0..v1.2.0 mencakup semua commit yang bisa dicapai dari v1.2.0 tetapi bukan dari v1.1.0 — persis konsep rentang log di Opsi git log . Sekarang kita baca sebagai calon pembaca: “Tambah kolom pencarian produk” jelas fitur; “Perbaiki tautan rusak di beranda” jelas perbaikan; dan “Siapkan rilis v1.2.0” — tidak dimaksudkan untuk pembaca sama sekali, itu langkah internal alur rilis. Draft log harus dipilah dan diterjemahkan, bukan ditelan bulat.

Pemilahan itu menghasilkan isi section 1.2.0:

  • Tambah kolom pencarian produk → ditulis ulang sebagai fitur di bawah Added;
  • Perbaiki tautan rusak di beranda → masuk Fixed;
  • Siapkan rilis v1.2.0 → dibuang — kegiatan rilis bukan perubahan yang dirasakan pengguna.

Hasil akhirnya persis berkas yang dicommit pada langkah 3 alur rilis kemarin:

bash 
cat CHANGELOG.md

Output yang Dihasilkan:

text 
# Changelog

Semua perubahan penting pada proyek ini didokumentasikan pada berkas ini.
Format mengikuti Keep a Changelog, dan penomoran versi mengikuti Semantic Versioning.

## [Belum Dirilis]

## [1.2.0] - 2026-10-28

### Added
- Kolom pencarian produk di halaman produk.

### Fixed
- Tautan rusak di halaman beranda.

## [1.1.0] - 2026-10-27

### Added
- Keranjang belanja.
- Halaman produk.

## [1.0.0] - 2026-10-27

### Added
- Halaman beranda.

[Belum Dirilis]: https://github.com/budi-santoso/toko/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/budi-santoso/toko/compare/v1.1.0...v1.2.0
[1.1.0]: https://github.com/budi-santoso/toko/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/budi-santoso/toko/releases/tag/v1.0.0

Anatomi Format Keep a Changelog #

Struktur berkas di atas mengikuti Keep a Changelog — konvensi yang paling banyak diikuti proyek open source. Bagiannya dari atas ke bawah:

  • # Changelog — judul, diikuti satu-dua kalimat pembuka yang menyatakan tujuan berkas dan konvensi formatnya.
  • ## [Belum Dirilis] — parkiran perubahan pasca-rilis terakhir; section ini terus diisi antar rilis lalu “dipindahkan” menjadi section versi baru saat rilis berikutnya.
  • ## [1.2.0] - 2026-10-28 — satu section per versi: nama versi dalam kurung siku, tanggal rilis dalam format ISO YYYY-MM-DD.
  • ### Added, ### Fixed — pengelompokan jenis perubahan. Keep a Changelog menetapkan enam label baku: Added (baru), Changed (berubah), Deprecated (akan dihapus), Removed (dihapus), Fixed (diperbaiki), Security (celah keamanan).
  • Entri satu baris per perubahan — kalimat pendek, sudut pandang pengguna, tanpa jargon internal.

Mengapa memakai label baku dan bukan judul bebas? Karena label yang stabil bisa dipindai mata dalam sekilas dan — kelak — diparsing alat otomatis. Label “What’s New” di proyek A dan “Pembaruan” di proyek B terasa hidup, tetapi tidak bisa dibandingkan antar proyek.

Tautan Versi ke Perbandingan Tag #

Empat baris terakhir CHANGELOG.md adalah definisi tautan gaya referensi Markdown — kita baca utuh bagian itu:

bash 
tail -n 4 CHANGELOG.md

Output yang Dihasilkan:

text 
[Belum Dirilis]: https://github.com/budi-santoso/toko/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/budi-santoso/toko/compare/v1.1.0...v1.2.0
[1.1.0]: https://github.com/budi-santoso/toko/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/budi-santoso/toko/releases/tag/v1.0.0

Berkas itu memuat nama contoh budi-santoso/toko — di proyek nyata, segmen itu diganti pemilik dan nama repositori sungguhan. Pola URL-nya dua macam. Pertama, perbandingan dua titik: compare/v1.1.0...v1.2.0 menampilkan daftar commit dan diff antara dua tag — GitHub merender halaman ini untuk repositori mana pun yang memuat kedua tag. Kedua, tautan rilis: releases/tag/v1.0.0 membuka halaman rilis yang menempel pada tag — dipakai untuk versi paling awal yang tidak punya titik pembanding sebelumnya. Bagi pembaca changelog, klik [1.2.0] langsung menjawab “bedanya apa dengan yang sebelumnya?” tanpa harus membuka terminal.

Konvensi ini tidak mensyaratkan jaringan: tautannya ditulis sebagai teks biasa, dan hanya aktif saat berkas dipublikasikan di hosting yang memahami pola tersebut — topik yang dibahas di Release dan Tags di Platform Hosting .

Disiplin: Changelog Ditulis Manusia #

Kita saksikan sendiri di atas: log hanya menyumbang draft; penilaian, pemilahan, dan penulisan ulang tetap pekerjaan manusia yang mengerti konteks. Kalimat “Tambah kolom pencarian produk” nyaris siap pakai, sedangkan commit merge, penataan ulang, dan catatan internal tidak layak terbit — mesin tidak tahu membedanya. Karena itu changelog paling sehat ditulis seiring perkembangan, bukan ditambal semalam sebelum rilis: tiap fitur yang selesai menyumbang satu baris ke section [Belum Dirilis], dan rilis tinggal memotongnya menjadi section versi baru — persis alur langkah 3 di Release Workflow .

Draft dari log, format baku, tautan versi — changelog yang baik menyusun ketiganya dengan disiplin. Satu lapis terakhir membuat seluruh bangunan ini dapat dipercaya: bagaimana pembuat rilis membuktikan bahwa tag v1.2.0 benar-benar keluar dari tangan yang berhak? Jawabannya adalah tanda tangan kriptografis — pokok chapter penutup section ini: Menandatangani Commit dan Tag .