Cara Menulis Pesan Commit Git yang Rapi dan Jelas

Enam bulan dari sekarang, seseorang akan menjalankan git log untuk memahami mengapa sebuah baris kode ada. Orang itu bisa rekan setim, bisa juga dirimu sendiri. Pesan commit yang baik menjawab pertanyaannya dalam hitungan detik, sedangkan pesan seperti "fix stuff" memaksanya membongkar diff satu per satu. Berikut tips praktis menulis pesan commit yang tetap berguna lama setelah kamu melakukan push.

Mengapa pesan commit penting

Kode menunjukkan apa yang berubah. Hanya pesan commit yang bisa menjelaskan mengapa. Riwayat yang rapi mempercepat code review, membantu anggota tim baru memahami proyek, dan membuat alat seperti git bisect, yang memakai pencarian biner untuk menemukan commit penyebab bug, jauh lebih efektif.

Anatomi pesan commit yang baik

Dokumentasi resmi Git menyarankan agar pesan diawali satu baris ringkasan pendek, kurang dari 50 karakter, lalu satu baris kosong, kemudian penjelasan yang lebih rinci. Banyak alat, termasuk git log --oneline dan sebagian besar layanan hosting Git, mengandalkan struktur ini.

Add offline save mode for mobile users

Players on unstable connections lost progress when
the save request timed out. Progress is now stored
locally and synced once the connection returns.

Fixes #142

Aturan 50/72

Jaga baris subjek sekitar 50 karakter dan bungkus isi pesan di kisaran 72 karakter per baris. Subjek pendek tetap terbaca di tampilan satu baris, dan isi yang dibungkus tampil rapi di terminal. Panduan populer dari Chris Beams, How to Write a Git Commit Message, membahas tujuh aturan ini secara lengkap.

Gunakan kalimat perintah

Tulis subjek sebagai perintah: "Add login rate limit", bukan "Added login rate limit" atau "Adds login rate limit". Cara mengujinya mudah: subjekmu harus bisa melengkapi kalimat "Jika diterapkan, commit ini akan…". Git sendiri memakai gaya ini untuk pesan yang dibuatnya otomatis, misalnya "Merge branch…". Jika timmu menulis commit dalam bahasa Indonesia, prinsipnya sama: "Tambahkan batas percobaan login".

Jelaskan alasannya, bukan caranya

Diff sudah memperlihatkan bagaimana kodenya diubah. Gunakan isi pesan untuk menjelaskan masalahnya, alasan memilih pendekatan tersebut, dan efek sampingnya. Buku Pro Git memberi saran serupa dalam panduannya tentang berkontribusi pada sebuah proyek.

Coba Conventional Commits

Untuk tim yang ingin format bersama, spesifikasi Conventional Commits menambahkan awalan tipe pada setiap subjek:

• feat: fitur baru

• fix: perbaikan bug

• docs:, refactor:, test:, dan tipe lain untuk pekerjaan pendukung

Format ini selaras dengan Semantic Versioning: fix setara dengan rilis patch, feat dengan rilis minor, dan BREAKING CHANGE dengan rilis mayor. Hasilnya, changelog dan nomor versi bisa dibuat secara otomatis. Gaya apa pun yang kamu pilih, sepakati satu konvensi dan terapkan secara konsisten di seluruh tim.

Kebiasaan yang menjaga riwayat tetap rapi

Buat commit kecil dan fokus

Satu perubahan logis untuk satu commit. Jika subjekmu butuh kata "dan", pertimbangkan untuk memecahnya. Commit kecil lebih mudah ditinjau, dibatalkan, dan dicari.

Hubungkan dengan issue

Sebutkan nomor tiket di isi pesan. Di GitHub, kata kunci seperti "Fixes #142" dapat menutup issue terkait secara otomatis saat perubahan masuk ke branch utama.

Periksa sebelum push

Sebelum push, telusuri riwayat terbarumu. Mengubah pesan commit lokal yang kurang jelas hanya butuh beberapa detik; menjelaskannya belakangan butuh waktu jauh lebih lama.

Pesan commit adalah surat untuk masa depan. Tulislah untuk orang yang memegang kodenya, tetapi tidak memiliki ingatanmu.

Jelajahi lebih lanjut

Riwayat yang rapi hanyalah satu bagian dari software berkualitas. Panduan kami tentang Core Web Vitals dengan bahasa sederhana membahas cara mengukur kecepatan produk yang kamu rilis, dan artikel agen AI kecil yang benar-benar berguna menunjukkan bagaimana otomatisasi bisa membantu pekerjaan sehari-hari. Temukan karya lainnya di Ryuartistry.