Aturan Commit Message di Github

Kalau kamu sering coding dan pakai Git, pasti tau rasanya bingung lihat commit history yang berantakan. Saya juga pernah di posisi itu. Dulu saya suka bikin commit message asal-asalan kayak "fix bug" atau "update code". Eh, giliran beberapa bulan kemudian pas mau debug, malah pusing sendiri karena ga ngerti apa yang saya ubah waktu itu 😅

Saya ingin share pengalaman dan hal-hal yang saya pelajari cara menulis commit message yang lebih baik. Ini bukan aturan baku yang harus diikuti 100%, tapi lebih ke panduan yang semoga bisa membantu kamu (dan tim kamu) lebih nyaman bekerja dengan Git.

Kenapa Sih Commit Message Itu Penting?

Jujur, dulu saya pikir commit message itu cuma formalitas. Ternyata setelah kerja di beberapa project, baru ngeh betapa pentingnya:

Dokumentasi Otomatis - Commit message jadi kayak diary perjalanan kode kita
Code Review Lebih Lancar - Reviewer ga perlu tebak-tebakan maksud kita apa
Debugging Lebih Cepat - Kalau ada bug, tinggal trace kapan dan kenapa kode berubah
Generate Changelog - Ada tools yang bisa bikin changelog otomatis dari commit message
Onboarding Lebih Gampang - Developer baru bisa cepet paham evolusi project

Struktur Dasar Commit Message

Okay, ini dia struktur yang umum dipakai dan cukup simpel:

<type>(<scope>): <subject>

<body>

<footer>

Mari kita bahas satu-satu ya.

1. Type - Jenis Perubahan

Type ini basically ngasih tau perubahan yang kita lakukan itu termasuk kategori apa. Ini yang paling umum dipakai:

Type	Deskripsi
feat	Menambahkan fitur baru
fix	Memperbaiki bug
docs	Perubahan dokumentasi saja
style	Perubahan format kode (spasi, indentasi, titik koma)
refactor	Refactoring kode tanpa mengubah fungsionalitas
perf	Perubahan yang meningkatkan performa
test	Menambah atau memperbaiki test
chore	Maintenance task (update dependencies, konfigurasi, dll)
ci	Perubahan pada CI/CD configuration
build	Perubahan pada build system atau dependencies
revert	Membatalkan commit sebelumnya

2. Scope (Opsional)

Scope itu kayak ngasih tau "bagian mana nih yang berubah?". Contohnya:

feat(auth): add OAuth2 login
fix(payment): resolve checkout crash
docs(readme): update installation steps

Scope ini membantu banget supaya developer langsung tau module mana yang kena impact.

3. Subject - Judul Commit

Ini adalah ringkasan singkat dari perubahan yang kita buat. Beberapa pedoman yang bisa diikuti:

Maksimal 50 karakter - Agar mudah dibaca di log
Gunakan imperative mood - "add" bukan "added" atau "adding"
Huruf kecil di awal - Tergantung konvensi tim (ada yang prefer huruf besar)
Tanpa titik di akhir - Subject bukan kalimat lengkap
Jelas dan deskriptif - Hindari "fix bug" atau "update code"

Contoh yang Baik:

feat: add user registration endpoint
fix: resolve memory leak in image processing
docs: update API documentation for v2

Contoh yang Buruk:

fixed a bug
updated stuff
minor changes

4. Body - Penjelasan Detail (Opsional)

Body ini buat jelasin lebih detail tentang apa yang berubah dan kenapa. Tips-nya:

Pisahkan dari subject dengan satu baris kosong
Usahain maksimal 72 karakter per baris biar rapi
Jelasin konteks dan alasan perubahan
Boleh pakai bullet points
Fokus ke "apa" dan "kenapa", bukan "bagaimana" (soalnya cara-nya udah keliatan di kode)

Contoh:

feat: add Redis caching for user sessions

Previous implementation stored sessions in database which
caused performance issues under high load.

Changes:
- Implement Redis adapter for session storage
- Add cache invalidation on user logout
- Configure 24-hour TTL for session keys

This improves response time by ~200ms on average.

Footer isinya informasi tambahan kayak:

Breaking changes: Perubahan yang tidak backward compatible
Issue references: Referensi ke issue tracker

Contoh:

BREAKING CHANGE: API endpoint /api/users now requires authentication

Closes #123
Fixes #456
Related to #789

Conventional Commits

Nah, Conventional Commits ini adalah standar yang lumayan populer dan banyak dipakai di industri. Format-nya kurang lebih sama kayak yang tadi kita bahas:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Enaknya pakai Conventional Commits:

Standar industri - Banyak digunakan di project open source
Tooling support - Banyak tools yang support format ini
Semantic versioning - Memudahkan generate version number otomatis
Changelog generation - Tools seperti standard-version bisa generate changelog

Contoh Implementasi Commit Message

Menambah Fitur Baru

feat(auth): implement two-factor authentication

Add 2FA support using TOTP (Time-based One-Time Password).
Users can enable 2FA in security settings and scan QR code
with authenticator apps like Google Authenticator.

Changes:
- Add TOTP generation and verification
- Create 2FA setup flow in user settings
- Update login flow to check 2FA status
- Add backup codes generation

Closes #234

Memperbaiki Bug

fix(cart): prevent duplicate items in shopping cart

Users reported items appearing multiple times when
clicking "Add to Cart" rapidly. Added debounce logic
and cart state validation to prevent duplicates.

Fixes #567

Refactoring

refactor(database): migrate from MongoDB to PostgreSQL

MongoDB proved difficult to scale with our relational data
structure. PostgreSQL offers better performance for our
use case with complex joins.

- Migrate all schemas to SQL
- Update ORM configuration
- Convert queries to SQL syntax
- Add migration scripts

BREAKING CHANGE: Database connection strings need to be updated
in environment configuration. See MIGRATION.md for details.

Dokumentasi

docs: add contributing guidelines

Create CONTRIBUTING.md with:
- Code style guidelines
- Pull request process
- Commit message conventions
- Testing requirements

Perubahan Style/Format

style: format code with Prettier

Run Prettier across entire codebase to ensure
consistent code formatting. No functional changes.

Menulis commit message yang rapi memang butuh sedikit usaha di awal, tapi manfaatnya besar untuk jangka panjang. Commit yang jelas bikin kamu (dan developer lain) lebih mudah memahami perubahan, bahkan setelah berbulan-bulan.