Belajar Semantic Release - Conventional Commits & Commit Message Standard

#Pendahuluan

Di episode 2 kita membedah arsitektur semantic-release: commit analyzer membaca riwayat commit dan menentukan jenis rilis. Sekarang kita belajar bahasa yang dibacanya — karena commit analyzer hanya sepintar format pesan commit yang kalian tulis. Commit yang berantakan sama saja dengan memberi mesin teks bahasa asing yang tidak bisa diurai.

Conventional Commits adalah spesifikasi ringan yang mengubah pesan commit menjadi format yang bisa diparse: type(scope): subject. Spesifikasi ini populer karena mudah dipelajari manusia dan mudah dibaca mesin — persis kombinasi yang dibutuhkan otomatisasi release. Tidak perlu menulis esai; cukup satu baris yang jujur tentang jenis perubahan.

#Pembahasan Utama

#Format Dasar

Format intinya hanya satu baris:

Format dasar: type(scope): subject

type(scope): subject
feat(auth): tambahkan halaman login
fix(validator): perbaiki validasi email

type: kata kunci wajib yang menyatakan jenis perubahan, misalnya feat atau fix.
scope: opsional, menandai bagian kode yang terpengaruh, misalnya auth, validator, api.
subject: ringkasan perubahan, ditulis imperatif, tanpa titik di akhir.

Subjek yang baik menjawab pertanyaan: "commit ini mengubah apa?" Secara visual: feat(auth): tambahkan halaman login berarti "di bagian auth, ada fitur baru berupa halaman login."

#Sepuluh Type yang Umum

Type	Arti	Contoh Subject
`feat`	Fitur baru	tambahkan halaman login
`fix`	Perbaikan bug	perbaiki validasi email
`perf`	Peningkatan performa	percepat render daftar
`refactor`	Perubahan internal, bukan bug	rapikan modul auth
`docs`	Perubahan dokumentasi	perbaiki panduan setup
`test`	Penambahan atau ubah test	tambah test login flow
`chore`	Tugas rutin non-fungsional	update dependensi keamanan
`build`	Perubahan build system	update config bundler
`ci`	Perubahan konfigurasi CI	pindah ke setup-node v4
`revert`	Membatalkan commit	kembalikan commit 3f2a1b0

#Dampak Type terhadap Rilis

Commit analyzer memetakan type ke jenis rilis. Dengan preset default, hanya feat dan fix yang memicu rilis; sisanya perlu diatur lewat releaseRules seperti yang dipakai repo ini.

Type	Dampak Rilis
`feat`	minor
`fix`, `hotfix`	patch
`perf`, `refactor`, `chore`, `revert`	patch
`docs`, `test`, `ci`, `style`	tidak ada rilis
Breaking change	major

Note

Default preset Angular hanya mengenali feat menaikkan minor dan fix menaikkan patch. Mapping tambahan seperti perf dan refactor menaikkan patch, atau chore memicu rilis, adalah hasil kustomisasi releaseRules — bukan perilaku bawaan. Kita akan menyusunnya sendiri di episode 5.

#Breaking Change

Perubahan yang merusak kompatibilitas ditandai dengan footer BREAKING CHANGE: atau tanda seru ! setelah type atau scope. Keduanya memicu rilis major.

Menandai breaking change dengan footer dan tanda seru

feat(auth): pindah ke token berbasis JWT
 
BREAKING CHANGE: format token lama tidak lagi didukung
 
feat!: drop dukungan Node 16

Catatan penting: kata kunci BREAKING CHANGE harus ada di footer, terpisah satu baris kosong dari subject. Repo ini bahkan mendaftarkan BREAKING CHANGE dan BREAKING CHANGES di parserOpts.noteKeywords agar kedua bentuk terbaca.

#Contoh Benar dan Salah

Commit yang benar dan yang menyesatkan

fix(auth): perbaiki login gagal saat email huruf kapital    # benar
feat: tambahkan halaman dashboard                           # benar
update validasi email                                       # salah
fix bug                                                     # salah

Kesalahan yang paling umum: tidak memakai type sama sekali, atau subject yang terlalu samar seperti fix bug — apa yang diperbaiki? di bagian mana? Mesin tidak bisa menebak, dan changelog yang dihasilkan akan tidak berguna.

Warning

fix bug dan update tidak bisa diparse sebagai fix. Akibatnya commit itu tidak memicu rilis, dan perbaikannya tidak pernah sampai ke user sampai commit lain yang berformat benar datang. Pesan commit yang malas adalah biaya tersembunyi: changelog ikut korup dan rilis tertunda.

#Tips Menulis Commit

Tulis subject imperatif dan pendek — batasi sekitar 50-72 karakter.
Gunakan lowercase untuk type dan subject.
Jangan akhiri subject dengan titik.
Pisahkan breaking change di footer, bukan di subject.
Jika sebuah perubahan besar, pecah menjadi beberapa commit kecil berformat — changelog akan jauh lebih terbaca.

Konvensi menulis subject commit

"tambahkan halaman login"     # imperatif
"tambah halaman login"        # tanpa titik
"menambahkan halaman login"   # bukan imperatif, hindari

#Penutup

Pada episode 3 ini kalian telah memahami:

Format type(scope): subject dengan type wajib dan scope opsional.
Sepuluh type umum: feat, fix, perf, refactor, docs, test, chore, build, ci, revert.
Mapping type ke rilis: feat minor, fix patch, breaking major.
Breaking change lewat footer BREAKING CHANGE: atau tanda seru !.

Di episode 4 kita akan melihat di mana commit-commit itu hidup: strategi branching Git Flow dengan staging sebagai release candidate dan main sebagai branch stable. Sampai jumpa di episode 4!