Menulis Commit Message yang Rapi dan Bermakna Menggunakan Conventional Commits

Bagi developer yang bekerja sendirian maupun dalam tim, riwayat commit sering menjadi "sejarah tak tertulis" dari sebuah proyek. Sayangnya, riwayat itu banyak sekali dipenuhi pesan seadanya seperti fix bug, update, atau perbaikan kecil yang beberapa bulan kemudian jadi tidak ada gunanya sama sekali saat harus melacak perubahan tertentu.

Di sinilah Conventional Commits hadir sebagai solusi: sebuah konvensi penulisan commit message yang sederhana, konsisten, dan mudah dibaca baik oleh manusia maupun oleh mesin (tools seperti changelog generator dan CI/CD).

Daftar Isi

1. Apa Itu Conventional Commits?
2. Daftar Type yang Umum Dipakai
3. Contoh Penerapan & Scope
4. Otomatisasi dengan Husky & Commitlint
5. Mengapa Ini Penting? (Semantic Release)

1. Apa Itu Conventional Commits?

Conventional Commits adalah spesifikasi ringan untuk menulis pesan commit dengan format yang sangat terstruktur:

Format dasarnya adalah:

<type>[optional scope]: <description>

[optional body]

[optional footer]

Format ini membuat setiap commit secara mudah menjelaskan apa yang berubah dan mengapa, tanpa harus membuat rekan tim Anda membuka diff kode satu per satu. Untuk mengetahui lebih lanjut, Anda dapat membaca spesifikasi lengkapnya di Conventional Commits. Selanjutnya mari kita bahas lebih dalam mengenai daftar type yang umum dipakai.

2. Daftar Type yang Umum Dipakai

Berikut adalah tipe-tipe (type) yang paling umum digunakan dalam Conventional Commits:

[!CATATAN] Satu catatan penting: style di sini merujuk pada gaya penulisan kode (formatting), bukan perubahan visual pada tampilan UI. Perubahan CSS yang mengubah tampilan UI sebaiknya tetap masuk kategori feat atau fix. Sama halnya dengan refactor juga tidak boleh mengubah perilaku/fitur yang sudah ada.

Selanjutnya bagaimana cara penulisan commit message yang benar? Mari kita lanjutkan ke bagian berikutnya.

3. Contoh Penerapan & Scope

Berikut contoh pesan commit dari pekerjaan sehari-hari dalam mengembangkan sebuah fitur survei:

feat: add social sharing links to event-text section
fix: resolve horizontal scroll on mobile caused by blur-bg scale
style: adjust padding on nps-btn for consistent spacing
refactor: extract survey score selection logic into separate function
docs: add comment explaining nps-grid column calculation

Perhatikan polanya: setiap pesan commit diawali kata kerja aktif (add, resolve, adjust, extract) dengan huruf kecil. Apakah Anda penasaran bagaimana cara menambahkan scope ke dalam commit message? Berikut adalah caranya.

Menambahkan Scope untuk Konteks Lebih Jelas

Pada proyek Enterprise dengan banyak modul (Monorepo), menambahkan scope (bagian dalam tanda kurung) sangat membantu tim mengetahui area kode yang terdampak:

feat(survey): add social sharing links to event-text section
fix(mobile): resolve horizontal scroll caused by blur-bg scale
fix(email): resolve SPF alignment issue on Exim configuration

Pada contoh di atas, scope ditambahkan dalam tanda kurung () setelah type. Penambahan scope ini memberikan konteks tambahan pada pesan commit, sehingga kita dapat dengan jelas mengetahui area mana saja yang terdampak oleh perubahan tersebut. Bagaimana jika perubahan yang dilakukan merusak kompabilitas versi sebelumnya, ada istilah breaking change untuk menandai perubahan tersebut. Lalu bagaimana cara menandainya?.

Menandai Breaking Change

Untuk perubahan yang merusak kompabilitas versi sebelumnya (backward-incompatible), gunakan tanda seru (!) sebelum titik dua:

feat!: change survey score API response structure

BREAKING CHANGE: response.data.score is now response.data.result.score

Pada contoh di atas, tanda seru (!) diletakkan tepat setelah type (feat) dan sebelum tanda titik dua (:). Ini berfungsi sebagai penanda cepat (fast indicator) bahwa commit ini memuat perubahan yang merusak kompatibilitas (breaking change).

Kemudian di bagian footer (area paling bawah dari commit message), kita menambahkan blok teks BREAKING CHANGE: yang langsung diikuti dengan penjelasan spesifik mengenai apa yang berubah secara drastis. Dalam kasus ini, kita menjelaskan bahwa struktur data response dari API telah bergeser dari response.data.score menjadi response.data.result.score. Penandaan ini sangat penting agar tim Frontend atau pengguna API lainnya bisa dengan cepat menyadari keharusan mereka untuk menyesuaikan kode.

4. Otomatisasi dengan Husky & Commitlint

Mengetahui aturan adalah satu hal, namun memaksakannya kepada seluruh anggota tim adalah hal lain. Sangat merepotkan jika Anda harus selalu mengoreksi pesan commit junior developer secara manual.

Solusinya adalah menggunakan Git Hooks untuk mencegah pesan yang salah masuk ke dalam repositori.

Di ekosistem JavaScript/Node.js, kita mengkombinasikan dua alat tangguh:

1. Husky: Alat pelari Git Hooks modern.
2. Commitlint: Linter khusus untuk mengecek format Conventional Commits.

Langkah-Langkah Instalasi:

1. Instal dependensi pengembangan:

npm install --save-dev @commitlint/{config-conventional,cli}
npm install --save-dev husky

2. Konfigurasi Commitlint: Buat file bernama commitlint.config.js di root proyek Anda:

// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional']
};

3. Inisialisasi Husky: Jalankan perintah ini untuk mengaktifkan Husky di proyek lokal Anda (pastikan sudah git init):

npx husky init

Perintah ini akan membuat folder .husky/ dan memodifikasi package.json Anda (menambahkan skrip prepare).

4. Tambahkan Hook commit-msg: Beri tahu Husky agar menjalankan Commitlint sesaat sebelum commit disimpan:

echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

Hasilnya di Terminal

Setelah konfigurasi di atas selesai, apa yang terjadi jika seorang developer mencoba melakukan commit sembarangan seperti git commit -m "fixed button"?

Seperti yang Anda lihat pada terminal di atas, Git akan langsung membatalkan commit tersebut! Terminal akan mengeluarkan laporan merah, memberitahu developer bahwa tipe commit-nya tidak valid (karena memakai kata fixed yang bukan merupakan konvensi baku, alih-alih fix). Selain itu, terminal akan memberikan beberapa saran, misalnya memperbaiki type ke fix dan menambahkan *scope` agar lebih jelas.

5. Mengapa Ini Penting? Semantic Release

Selain untuk kerapian, keuntungan terbesar dari Conventional Commits akan terasa saat dipadukan dengan CI/CD pipeline modern (seperti Semantic Release).

Jika Anda disiplin menggunakan format ini, tools otomatis dapat membaca riwayat Git Anda dan seketika melakukan hal berikut tanpa campur tangan manusia:

1. Versioning Otomatis: Jika ada feat!, naikkan versi Major (v1.0.0 -> v2.0.0). Jika ada feat, naikkan versi Minor (v1.0.0 -> v1.1.0). Jika hanya fix, naikkan versi Patch (v1.0.0 -> v1.0.1).
2. Changelog Generator: Skrip akan memisahkan otomatis mana baris fitur baru dan mana baris perbaikan bug, lalu menuliskannya ke dalam file CHANGELOG.md yang rapi.

Riwayat debugging enam bulan kemudian (menggunakan git log --oneline) tidak lagi menjadi tumpukan teks "update fix", melainkan dokumentasi evolusi produk yang terstruktur.

Menulis commit message yang baik bukan sekadar tentang estetika,ini adalah bentuk komunikasi asinkron terbaik untuk tim Anda dan investasi jangka panjang (Technical Wealth) bagi proyek yang Anda bangun.

Cobalah terapkan Conventional Commits dan Commitlint hari ini di proyek Anda, dan rasakan kebahagiaan saat melihat riwayat Git yang seragam.