Conventional Commits

Struktur subjek–body dari chapter Menulis Commit Message membuat pesan nyaman dibaca manusia. Tim yang lebih besar menuntut satu hal lagi: format yang bisa dibaca mesin. Ketika ratusan commit bercampur setiap bulan, menyusun changelog rilis dan memutuskan naik versi minor atau major lewat tangan itu pekerjaan lambat dan rawan kelewat. Conventional Commits adalah konvensi ringkas yang ditumpangkan di atas struktur pesan — cukup satu prefiks kecil pada subjek — sehingga riwayat tetap enak dibaca orang sekaligus bisa diurai otomatis. Chapter ini membahas formatnya, tabel tipenya, penanda perubahan besar, dan demonstrasinya pada repository sungguhan.

Format type(scope): deskripsi #

Bentuk dasarnya satu baris:

fix(auth): perbaiki validasi token

Tiga bagiannya:

1. type — kelas perubahan: fix untuk perbaikan galat, feat untuk fitur baru, dan seterusnya sesuai tabel di bawah.
2. scope (opsional) — bagian kode yang disentuh, ditulis dalam kurung: auth, ui, docs. Scope membantu pembaca menautkan perubahan ke modul tertentu.
3. deskripsi — kalimat imperatif yang sama persis dengan aturan chapter sebelumnya; kini subjek utuhnya adalah type(scope): deskripsi, jadi anggaran 50 karakter dihitung termasuk prefiks.

Body, baris kosong pemisah, dan seluruh aturan penulisan dari chapter sebelumnya tetap berlaku tanpa perubahan. Konvensi lengkapnya terdokumentasi di conventionalcommits.org — termasuk terjemahan resmi bahasa Indonesia.

Tabel Type dan Kapan Dipakainya #

Type ditulis huruf kecil semuanya; daftar di atas adalah inti yang lazim, dan tim boleh menyesuaikan tanpa mengubah aturan dasarnya.

Empat Commit Konvensional dalam Praktik #

Kita bangun aplikasi tugas kecil dan mencatat setiap langkah dengan format ini:

mkdir latihan-conventional && cd latihan-conventional
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf '# Aplikasi Tugas\n\nKelola daftar tugas harian.\n' > README.md
printf 'TAMBAH "belajar git"\nTAMBAH "tulis laporan"\n' > tugas.txt
printf 'def periksa_token(token):\n    return len(token) > 0\n' > auth.py
git add README.md tugas.txt auth.py
git commit -m "feat: tambah kerangka aplikasi tugas"

Output yang Dihasilkan:

[main (root-commit) 987e058] feat: tambah kerangka aplikasi tugas
 3 files changed, 7 insertions(+)
 create mode 100644 README.md
 create mode 100644 auth.py
 create mode 100644 tugas.txt

Commit kedua menambah kemampuan pencarian — kelas feat, tanpa scope karena perubahannya menyentuh aplikasi secara umum:

printf 'def cari(judul, daftar):\n    return [t for t in daftar if judul in t]\n' > pencarian.py
git add pencarian.py
git commit -m "feat: tambah pencarian judul tugas"

Output yang Dihasilkan:

[main daa13d7] feat: tambah pencarian judul tugas
 1 file changed, 2 insertions(+)
 create mode 100644 pencarian.py

Commit ketiga memperbaiki galat pada modul autentikasi — kelas fix dengan scope auth:

printf 'def periksa_token(token):\n    return token is not None and len(token) > 10\n' > auth.py
git add auth.py
git commit -m "fix(auth): perbaiki validasi token"

Output yang Dihasilkan:

[main 421ec06] fix(auth): perbaiki validasi token
 1 file changed, 1 insertion(+), 1 deletion(-)

Commit keempat hanya menyentuh dokumentasi:

printf '# Aplikasi Tugas\n\nKelola daftar tugas harian.\n\nJalankan: python3 tugas.py\n' > README.md
git add README.md
git commit -m "docs: perbarui README cara menjalankan"

Output yang Dihasilkan:

[main 7e17599] docs: perbarui README cara menjalankan
 1 file changed, 2 insertions(+)

Riwayat yang terbentuk kini punya ritme yang langsung terbaca:

git log --oneline

Output yang Dihasilkan:

7e17599 docs: perbarui README cara menjalankan
421ec06 fix(auth): perbaiki validasi token
daa13d7 feat: tambah pencarian judul tugas
987e058 feat: tambah kerangka aplikasi tugas

Tanpa membuka satu pun diff, empat baris itu sudah bercerita: satu fitur kerangka, satu fitur pencarian, satu perbaikan pada auth, satu pembaruan dokumentasi. Prefiks membuat riwayat bisa dipindai sekilas — dan bisa disaring dengan git log --grep="^fix" sebagaimana dibahas di chapter Opsi git log .

Menandai Perubahan Besar dengan BREAKING CHANGE #

Perubahan yang merusak kompatibilitas — API berganti bentuk, format berkas berubah — ditandai dua cara yang boleh dipakai bersamaan. Pertama, tanda seru setelah type atau scope: feat!: atau feat(auth)!:. Kedua, footer BREAKING CHANGE: pada akhir body. Kita uji keduanya pada perubahan format penyimpanan tugas:

printf 'ID-1|belajar git\nID-2|tulis laporan\n' > tugas.txt
git add tugas.txt
cat > pesan-breaking.txt <<'EOF'
feat!: ubah format penyimpanan tugas

Berkas tugas.txt kini menyimpan baris "ID|judul" agar setiap tugas
punya pengenal stabil untuk ditautkan ke catatan lain.

BREAKING CHANGE: skrip yang mengurai format lama TAMBAH "judul"
harus disesuaikan ke format ID|judul.
EOF
git commit -F pesan-breaking.txt

Output yang Dihasilkan:

[main 1b54aa3] feat!: ubah format penyimpanan tugas
 1 file changed, 2 insertions(+), 2 deletions(-)

Struktur lengkap pesannya tersimpan utuh di objek commit:

git log -1

Output yang Dihasilkan:

commit 1b54aa35659ccd4870f4401c466aa60e3e2a4e62
Author: Budi Santoso <[email protected]>
Date:   Tue Oct 13 09:40:00 2026 +0700

    feat!: ubah format penyimpanan tugas
    
    Berkas tugas.txt kini menyimpan baris "ID|judul" agar setiap tugas
    punya pengenal stabil untuk ditautkan ke catatan lain.
    
    BREAKING CHANGE: skrip yang mengurai format lama TAMBAH "judul"
    harus disesuaikan ke format ID|judul.

Tanda seru membuat penanda terlihat bahkan pada tampilan --oneline yang pendek, sementara footer menjelaskan apa yang harus dilakukan pemakai versi lama. Keduanya bagian resmi pesan — mengikuti aturan hash dari chapter Anatomi Commit .

Dari Format ke Otomasi #

Nilai sesungguhnya format ini muncul saat riwayat diurai mesin. Karena setiap subjek diawali type yang baku, alat rilis bisa mengelompokkan commit sejak rilis terakhir — seluruh feat menjadi bagian fitur baru di changelog, seluruh fix menjadi bagian perbaikan — tanpa siapa pun membaca ulang ratusan pesan. Aturan naik versinya mengikuti Semantic Versioning : kehadiran BREAKING CHANGE menaikkan versi major, feat menaikkan minor, dan fix menaikkan patch. Alat otomasi rilis populer seperti semantic-release dan pembuat changelog seperti git-cliff memang membaca format ini; yang mereka butuh hanyalah konsistensi tim menulis prefiksnya.

Riwayat akhir aplikasi tugas kita, lengkap dengan penanda besar di ujungnya:

git log --oneline

Output yang Dihasilkan:

1b54aa3 feat!: ubah format penyimpanan tugas
7e17599 docs: perbarui README cara menjalankan
421ec06 fix(auth): perbaiki validasi token
daa13d7 feat: tambah pencarian judul tugas
987e058 feat: tambah kerangka aplikasi tugas

Pesan yang berkualitas dan berformat kini berada dalam jangkauan satu perintah singkat. Namun git commit masih menyimpan sejumlah opsi yang mengubah perilakunya — dari pintasan staging sampai penulisan ulang commit terakhir — dan opsi-opsi itulah peta chapter berikutnya: Opsi git commit .