Pesan Git Commit: Aturan, Contoh, dan Konvensi

Mengapa Pesan Git Commit Itu Penting

Pesan commit menjelaskan perubahan Anda kepada siapa pun yang membaca kode nanti, termasuk diri Anda di masa depan.

Tiga bulan dari sekarang, Anda tidak akan ingat mengapa Anda melakukan refactor pada pipeline data itu atau mengapa Anda beralih dari pandas ke polars untuk operasi tertentu. Pesan commit Anda adalah satu-satunya catatan atas alasan Anda. Tanpanya, Anda hanya bisa menebak atau menggali thread Slack dan tiket JIRA.

Berikut beberapa alasan konkret lainnya mengapa pesan git commit itu penting.

Code review berjalan lebih cepat dengan pesan commit yang jelas. Reviewer Anda dapat memindai pesan, memahami niat, dan fokus pada apakah implementasinya sesuai. Pesan yang samar memaksa reviewer untuk membalikkan rekayasa pemikiran Anda hanya dari diff saja.

Debugging juga menjadi lebih mudah. Saat bug muncul, Anda akan menggunakan git log atau git blame untuk menelusuri kapan kode bermasalah diperkenalkan. Pesan seperti "fix authentication bug" tidak memberi tahu apa pun. Pesan seperti "fix token expiration check in auth middleware" langsung mengarahkan Anda ke masalahnya.

Kolaborasi tim bergantung pada riwayat yang mudah dibaca. Saat seseorang bergabung ke proyek Anda atau melanjutkan pekerjaan Anda, mereka akan membaca commit untuk memahami bagaimana codebase berevolusi. Pesan yang jelas mengubah riwayat Git Anda menjadi dokumentasi yang benar-benar membantu.

Intinya, menulis pesan commit yang deskriptif memakan waktu 15–30 detik. Namun itu menghemat berjam-jam kebingungan di kemudian hari.

Prinsip Inti Pesan Git Commit yang Baik

Pesan commit yang baik mengikuti beberapa prinsip sederhana—tidak lebih dari itu.

Tulis untuk pembaca di masa depan

Pesan commit Anda bukan untuk Anda saat ini—melainkan untuk siapa pun yang membacanya enam bulan dari sekarang.

Orang itu mungkin anggota tim baru yang mencoba memahami mengapa codebase bekerja dengan cara tertentu. Bisa jadi Anda sendiri, yang mencoba mengingat mengapa Anda mengambil keputusan tertentu. Apa pun itu, mereka tidak memiliki konteks yang Anda miliki hari ini.

Fokus pada niat dan alasan, bukan hanya apa yang berubah. Diff menunjukkan apa yang berubah. Pesan Anda harus menjelaskan mengapa berubah dan masalah apa yang diselesaikan.

Jelas dan ringkas

Pesan singkat yang deskriptif lebih mudah dipindai saat Anda melihat lusinan commit.

Pesan seperti "add caching" samar. Pesan seperti "add Redis caching for API responses" memberi tahu Anda persis apa yang terjadi. Anda dapat membacanya di git log --oneline dan langsung tahu apa yang dilakukan commit tersebut.

Baris subjek harus menjawab: apa yang dilakukan commit ini? Jika Anda perlu lebih dari 50–60 karakter untuk menjawabnya, kemungkinan Anda meng-commit terlalu banyak perubahan sekaligus.

Konsisten

Konsistensi di seluruh repositori membuat riwayat dapat diprediksi dan lebih mudah dipahami.

Saat setiap commit mengikuti format yang sama, Anda dapat cepat memindai riwayat. Anda tahu di mana mencari jenis perubahan, cakupan, dan deskripsi. Tim yang menerapkan format konsisten juga bisa mengotomatisasi tugas seperti membuat changelog atau memfilter commit berdasarkan tipe.

Pilih satu gaya dan patuhi itu. Jika tim Anda menggunakan bentuk imperatif waktu kini, jangan tiba-tiba beralih ke waktu lampau.

Jelaskan apa dan mengapa (bukan bagaimana)

Kode memperlihatkan bagaimana Anda menyelesaikan masalah. Pesan commit Anda harus menjelaskan apa masalahnya dan mengapa Anda memilih solusi ini.

Jangan tulis "refactored load_data() to use list comprehension instead of for loop." Tulis "speed up data loading by 40% for large CSV files." Pesan pertama menjelaskan perubahan kode. Pesan kedua menjelaskan dampaknya.

Tambahkan konteks saat itu membantu pembaca di masa depan memahami keputusan Anda. Jika Anda mencoba tiga pendekatan berbeda sebelum memilih yang ini, sebutkan. Jika ada bug report atau keputusan desain terkait, referensikan.

Struktur Pesan Git Commit

Sebagian besar pesan Git commit mengikuti struktur tiga bagian standar: baris subjek, isi, dan footer.

Baris subjek

Baris subjek adalah ringkasan satu baris yang muncul di git log --oneline dan daftar pull request.

Usahakan di bawah 50 karakter jika memungkinkan, maksimal 72. Batas ini memastikan pesan tampil dengan baik di output terminal dan UI GitHub tanpa terpotong. Jika Anda tidak bisa merangkum dalam 50 karakter, kemungkinan Anda mencoba menggambarkan terlalu banyak perubahan dalam satu commit.

Gunakan bentuk imperatif—tulis "add feature" alih-alih "added feature" atau "adds feature." Anggaplah melengkapi kalimat "Jika diterapkan, commit ini akan...". Jadi "Jika diterapkan, commit ini akan add Redis caching" terdengar natural, sementara "Jika diterapkan, commit ini akan adds Redis caching" tidak.

Contoh:

• fix null pointer exception in data loader

• add caching layer for API responses

• remove deprecated pandas functions

Isi (jika diperlukan)

Lewati isi untuk perubahan sederhana. Jika baris subjek sudah sepenuhnya menjelaskan commit, selesai.

Tambahkan isi saat Anda perlu menjelaskan mengapa Anda membuat perubahan atau memberikan konteks yang membantu pembaca di masa depan. Sisakan satu baris kosong antara subjek dan isi—Git menggunakan ini untuk memisahkan dua bagian.

Isi harus menjawab pertanyaan seperti: Masalah apa yang diselesaikan? Mengapa Anda memilih pendekatan ini? Adakah efek samping atau batasan? Apakah Anda mempertimbangkan solusi lain?

Bungkus baris pada 72 karakter untuk menjaga keterbacaan di output terminal. Sebagian besar editor teks dapat melakukannya secara otomatis.

Contoh:

add Redis caching for API responses

API response times were hitting 2-3 seconds for repeated queries.
Added Redis with 5-minute TTL to cache query results. This drops
response time to ~50ms for cached queries.

Considered using in-memory cache but Redis lets us scale horizontally
if needed.

Footer (opsional)

Gunakan footer untuk mereferensikan isu, pull request, atau perubahan yang bersifat breaking.

Jika commit Anda memperbaiki isu GitHub, tambahkan Fixes #123 atau Closes #456 di footer. GitHub akan otomatis menutup isu saat commit digabungkan. Untuk perubahan breaking, tambahkan BREAKING CHANGE: diikuti deskripsi tentang apa yang rusak dan cara migrasi.

Contoh:

remove support for Python 3.7

Python 3.7 reached end-of-life in June 2023. This commit drops
support and updates minimum version to Python 3.8.

BREAKING CHANGE: Python 3.7 users must upgrade to 3.8 or later.
Closes #789

Anda tidak memerlukan footer untuk sebagian besar commit—hanya saat menautkan referensi eksternal atau menandai perubahan breaking.

Jenis Pesan Git Commit Umum dan Kapan Menggunakannya

Banyak proyek menggunakan prefiks tipe commit untuk mengkategorikan perubahan secara sekilas.

Anda tidak perlu menghafal daftar label yang ketat. Tujuannya membantu pembaca cepat mengidentifikasi jenis perubahan yang terjadi tanpa membaca seluruh diff.

Berikut empat kategori yang perlu diketahui:

• Perubahan fitur memperkenalkan fungsionalitas baru. Gunakan prefiks seperti feat: atau add: saat Anda membangun sesuatu yang baru—endpoint API baru, fungsi pemrosesan data, atau fitur untuk pengguna. Contoh: feat: add CSV export for analysis results.

• Perbaikan bug menyelesaikan masalah yang ada. Gunakan fix: saat Anda mengoreksi perilaku yang tidak berjalan sebagaimana mestinya. Ini bisa apa saja dari null pointer exception hingga perhitungan yang keliru pada model Anda. Contoh: fix: handle missing values in preprocessing pipeline.

• Pembaruan dokumentasi meningkatkan komentar kode, berkas README, atau dokumentasi inline. Gunakan docs: saat Anda tidak mengubah cara kerja kode, hanya menjelaskannya dengan lebih baik. Contoh: docs: add usage examples for data loader class.

• Refactor dan pekerjaan pemeliharaan meningkatkan struktur kode tanpa mengubah perilaku. Gunakan refactor: saat Anda menata ulang kode agar lebih bersih atau mudah dirawat. Gunakan chore: untuk tugas rutin seperti memperbarui dependensi atau mengubah konfigurasi build. Contoh: refactor: extract validation logic into separate module atau chore: update pandas to 3.0.0.

Pilih tipe yang paling menggambarkan perubahan Anda dan lanjutkan—konsistensi lebih penting daripada memilih label yang "sempurna".

Aturan untuk Menulis Pesan Git Commit yang Lebih Baik

Berikut daftar periksa aturan yang akan membuat pesan commit Anda lebih berguna.

• Jaga baris subjek di bawah 50 karakter. Ini menjamin tampil dengan baik di git log --oneline, daftar commit GitHub, dan output terminal tanpa terpotong. Jika tidak muat dalam 50 karakter, targetkan maksimal 72.

• Gunakan bentuk imperatif. Tulis "add feature" alih-alih "added feature" atau "adds feature." Baris subjek Anda harus melengkapi kalimat "Jika diterapkan, commit ini akan...". Jadi "Jika diterapkan, commit ini akan add caching" sudah benar.

• Pisahkan subjek dan isi dengan satu baris kosong. Git menggunakan baris kosong ini untuk membedakan ringkasan dan penjelasan detail. Tanpanya, alat Git bisa menampilkan pesan Anda secara keliru.

• Lewati titik di akhir baris subjek. Anda menghemat karakter dan baris subjek bukan kalimat lengkap. Tulis fix null pointer in loader alih-alih fix null pointer in loader.

• Kapitalisasi kata pertama pada baris subjek. Tulis Add caching for API calls alih-alih add caching for API calls. Ini menjaga riwayat commit Anda tampak konsisten dan profesional.

• Gunakan isi untuk menjelaskan mengapa, bukan apa. Diff menunjukkan apa yang berubah. Isi Anda harus menjelaskan alasan di balik perubahan, pendekatan alternatif yang dipertimbangkan, dan trade-off yang dibuat.

• Bungkus teks isi pada 72 karakter. Ini mencegah masalah pelipatan baris di output terminal dan menjaga pesan commit tetap mudah dibaca di berbagai alat.

• Buat setiap commit bersifat atomik. Satu perubahan logis per commit. Jika Anda memperbaiki bug dan melakukan refactor kode, pecah menjadi dua commit dengan pesan terpisah.

Contoh Pesan Git Commit yang Baik

Berikut contoh nyata yang menunjukkan seperti apa pesan commit yang baik untuk berbagai skenario.

Perbaikan sederhana

fix: handle NaN values in feature engineering

The preprocessing pipeline crashed when encountering NaN values
in the 'age' column. Added fillna() with median imputation before
scaling features.

Ini berhasil karena mengidentifikasi masalah (crash karena NaN), menjelaskan di mana terjadinya (pipeline preprocessing, kolom age), dan menggambarkan solusinya (imputasi median).

Fitur baru

feat: add model performance tracking to MLflow

Added automatic logging of model metrics, parameters, and artifacts
to MLflow after each training run. This replaces our manual CSV
logging and makes experiment comparison much easier.

Metrics tracked: accuracy, precision, recall, F1 score
Training time also logged for performance monitoring.

Commit fitur yang baik menjelaskan apa yang Anda bangun, mengapa berguna, dan detail apa pun yang membantu pembaca memahami cakupannya.

Refactor

refactor: split data_loader.py into separate modules

Moved dataset classes to datasets.py, transformation logic to
transforms.py, and utility functions to utils.py. The original
file was 800+ lines and hard to navigate.

No behavior changes - all tests still pass.

Pesan refactor harus memperjelas bahwa Anda tidak mengubah fungsionalitas, hanya struktur. Baris "all tests still pass" meyakinkan reviewer.

Pembaruan dokumentasi

docs: add examples for custom loss functions

Previous documentation showed only built-in loss functions.
Added three examples: weighted cross-entropy, focal loss, and
custom regression loss with L1 regularization.

Each example includes code and explanation of when to use it.

Commit dokumentasi harus menjelaskan apa yang Anda dokumentasikan dan mengapa itu diperlukan.

Mereferensikan isu atau tiket

fix: prevent memory leak in batch processing

Large datasets caused memory usage to grow unbounded during batch
processing. The issue was holding references to processed batches
in the results list.

Changed to yield results instead of accumulating them in memory.
Memory usage now stays constant regardless of dataset size.

Fixes #247

Saat Anda mereferensikan isu, sertakan konteks yang cukup agar seseorang dapat memahami perbaikannya tanpa mengklik tiket. Fixes #247 di bagian bawah memberi tahu GitHub untuk menutup isu secara otomatis saat commit ini digabungkan.

Semua contoh mengikuti pola yang sama: mulai dengan apa yang berubah, jelaskan alasannya, tambahkan konteks yang membantu pembaca di masa depan, dan referensikan isu terkait jika relevan.

Conventional Commits sebagai Standar Pesan Git Commit

Conventional commits adalah format populer yang menambahkan struktur pada pesan commit melalui pola prefiks sederhana.

Format dasar

Formatnya seperti ini: type(scope): description.

Tipe mendeskripsikan jenis perubahan yang Anda buat—feat untuk fitur, fix untuk perbaikan bug, docs untuk dokumentasi, refactor untuk penataan ulang kode, dan seterusnya. Scope bersifat opsional dan menentukan bagian codebase yang berubah—seperti (auth) atau (api). Description menjelaskan apa yang Anda lakukan.

Contoh:

feat(api): add endpoint for batch predictions
fix(auth): prevent token expiration edge case
docs(readme): add installation instructions for Windows
refactor(data): extract validation logic to separate module

Ingatlah bahwa ini adalah konvensi, bukan keharusan. Git tidak peduli apakah Anda menggunakan format ini. Ini terutama tergantung pada keputusan tim tentang bagaimana menyusun pesan Anda demi konsistensi dan tooling.

Kapan conventional commits berguna

Tim yang mengotomatisasi proses rilis mendapatkan nilai paling besar dari conventional commits.

Alat dapat mengurai riwayat commit Anda dan secara otomatis membuat changelog. Saat Anda menandai rilis, alat memindai commit sejak rilis terakhir, mengelompokkannya berdasarkan tipe (feat, fix, docs), dan membuat changelog terformat. Ini menghemat pekerjaan manual untuk melacak apa yang berubah antar versi.

Conventional commits juga mendukung otomatisasi penomoran versi semantik. Jika semua commit sejak rilis terakhir adalah perbaikan, alat akan menaikkan versi patch (1.2.3 → 1.2.4). Jika Anda menambahkan fitur, versi minor naik (1.2.3 → 1.3.0). Perubahan breaking memicu kenaikan versi mayor (1.2.3 → 2.0.0).

Namun jika tim Anda tidak menggunakan rilis otomatis atau pembuatan changelog, conventional commits bisa terasa berlebihan. Strukturnya lebih membantu mesin daripada manusia, jadi pertimbangkan hal itu.

Kesalahan Umum Pesan Git Commit yang Perlu Dihindari

Bahkan developer berpengalaman terkadang membuat kesalahan saat menulis pesan commit, tetapi itu lebih karena rasa malas daripada kurangnya pengetahuan.

Berikut beberapa kesalahan yang harus Anda hindari.

Pesan yang samar atau generik

Pesan seperti "fix bug" atau "update code" tidak memberi tahu apa pun kepada pembaca di masa depan.

Saat Anda mencari perubahan tertentu di git log, Anda akan memindai lusinan commit. Pesan yang berbunyi "fix bug" memaksa Anda membuka diff dan membaca kode untuk memahami apa yang diperbaiki. Pesan yang berbunyi "fix null pointer in data preprocessing" langsung memberi tahu apakah ini commit yang Anda cari.

Pesan generik membuang waktu semua orang. Jika Anda tidak cukup ingat apa yang Anda ubah untuk menulis pesan spesifik, kemungkinan Anda belum siap melakukan commit.

Mencampur perubahan yang tidak terkait

Satu commit harus berisi satu perubahan logis.

Saat Anda memperbaiki bug dan melakukan refactor kode yang tidak terkait dalam satu commit, Anda mempersulit code review dan membuat git bisect tidak berguna. Jika commit itu memperkenalkan regresi, seseorang harus mengurai bagian mana yang menyebabkannya. Jika mereka ingin membatalkan hanya perbaikan bug, tidak bisa—mereka juga akan membatalkan refactor.

Anda harus selalu memisahkan perubahan menjadi commit terpisah. Perbaiki bug dalam satu commit, refactor di commit lain. Setiap commit harus bisa dibatalkan secara mandiri tanpa merusak codebase.

Jika Anda sudah mencampur perubahan secara lokal, gunakan git add -p untuk menyimpan bagian-bagian file secara terpisah dan meng-commit-nya dalam potongan logis.

Membiarkan pesan work-in-progress

Commit dengan pesan seperti "WIP" atau "temp fix" tidak masalah secara lokal tetapi tidak boleh masuk ke branch utama.

Sebelum menggabungkan feature branch Anda, rapikan riwayat commit. Squash commit WIP menjadi commit yang bermakna dengan pesan yang tepat. Ubah "asdf" dan "trying something" menjadi deskripsi yang menjelaskan apa yang sebenarnya Anda lakukan.

Gunakan git rebase -i untuk menggabungkan commit, menulis ulang pesan, dan mengurutkan ulang perubahan sebelum mendorong. Tim Anda seharusnya melihat riwayat bersih tentang apa yang berubah dan mengapa, bukan proses debugging Anda.

Praktik Terbaik untuk Tim yang Menggunakan Pesan Git Commit

Jika tim Anda ingin membuat riwayat Git benar-benar berguna, Anda memerlukan konsistensi. Berikut beberapa praktik terbaik yang perlu diikuti.

Sepakati gaya bersama sejak awal. Putuskan apakah Anda akan menggunakan conventional commits, format kustom, atau hanya seperangkat aturan dasar. Pilih satu pendekatan dan jalankan di seluruh tim. Ketika setengah commit Anda bertuliskan "feat: add feature" dan separuh lainnya bertuliskan "Added new feature", riwayat Anda menjadi lebih sulit dipindai dan automasi bisa rusak.

Gaya tidak sepenting kepatuhan semua orang. Beberapa tim menyukai bentuk imperatif waktu kini ("add feature"), yang lain menggunakan waktu lampau ("added feature"). Keduanya baik-baik saja jika diterapkan secara konsisten.

Dokumentasikan konvensi Anda di tempat yang mudah diakses. Tambahkan berkas CONTRIBUTING.md ke repo Anda yang menjelaskan format pesan commit dengan contoh. Sertakan dalam dokumen onboarding untuk anggota tim baru. Saat seseorang bertanya "bagaimana saya harus memformat commit ini?", arahkan ke dokumentasi alih-alih menjelaskannya lagi.

Dokumentasi Anda harus mencakup format dasar yang digunakan, kapan menambahkan isi versus hanya subjek, cara mereferensikan isu atau tiket, dan beberapa contoh nyata dari repo Anda.

Gunakan pesan commit saat code review. Pesan commit yang baik membuat review pull request lebih cepat dan fokus. Reviewer dapat membaca pesan commit untuk memahami progres perubahan sebelum terjun ke kode.

Saat meninjau, periksa pesan commit seperti Anda memeriksa kode. Jika pesan samar atau menyesatkan, minta untuk ditulis ulang sebelum digabungkan. PR dengan commit yang jelas lebih mudah ditinjau, lebih mudah dibatalkan jika diperlukan, dan lebih mudah dipahami nanti.

Kesimpulan

Pesan commit yang jelas membutuhkan waktu 30 detik untuk ditulis tetapi menghemat berjam-jam kebingungan di kemudian hari.

Anggap riwayat commit Anda sebagai dokumentasi yang hidup bersama kode Anda. Saat Anda menulis "fix bug" alih-alih "fix null pointer in data preprocessing", Anda membuang waktu semua orang yang membaca commit itu nanti—termasuk diri Anda sendiri.

Perlakukan pesan commit Anda seperti kode. Jika Anda tidak akan mendorong kode yang ceroboh dan tanpa komentar ke produksi, jangan mendorong pesan commit yang ceroboh juga. Gunakan bentuk imperatif, jaga baris subjek di bawah 50 karakter, jelaskan alasan di isi bila diperlukan, dan buat setiap commit bersifat atomik.

Sekarang Anda tahu cara menulis pesan commit yang bermakna. Untuk meningkatkan keterampilan Anda, daftar di kursus Intermediate Git kami.