Code Commit

Perubahan dalam satu commit

Anggap satu commit sebagai satu langkah dalam rangkaian pekerjaan yang berjalan maju. Developer lain harus bisa melihat perkembangan pekerjaanmu dari rangkaian commit tersebut dengan jelas dan mudah dipahami.

Konvensi

• berdiri sendiri sebagai satu perubahan yang utuh dan logis
• tidak memuat perubahan lain dari task atau perbaikan yang berbeda
• punya commit message yang menjelaskan isinya (lihat di bawah)

Commit message

Commit message yang jelas sangat penting karena alasan berikut:

• Memudahkan penelusuran git history (misal: mengabaikan perubahan style)
• Pembuatan changelog secara otomatis
• Langkah CI/CD pipeline berbasis commit (misal: tidak menjalankan build dan deploy kalau perubahannya hanya dokumentasi atau styling)

Konvensi

Pakai format berikut,

type(scope): [issue] subject

body

type wajib ada dan harus salah satu dari berikut:

• feat: Fitur baru
• fix: Perbaikan bug
• build: Perubahan terkait build (misal: terkait npm/ menambah dependency eksternal)
• chore: Perubahan kode yang tidak terlihat oleh user luar (misal: perubahan file .gitignore atau .prettierrc)
• docs: Perubahan terkait dokumentasi
• refactor: Kode yang tidak memperbaiki bug dan tidak menambah fitur. (misal: dipakai saat ada perubahan semantik seperti mengganti nama variabel/ nama fungsi)
• perf: Kode yang meningkatkan performa
• style: Perubahan terkait style kode atau lint (misal: memperbaiki indentasi, titik koma yang hilang, atau spasi)
• test: Menambah test baru atau mengubah test yang sudah ada

scope opsional dan harus mengikuti aturan berikut:

• Frasa yang menjelaskan bagian kode yang terpengaruh perubahan. Contoh "(seeder)" atau "(middleware)"
• Huruf kecil dengan tanda hubung (-) sebagai pemisah. Contoh "(web-server)" atau "(storage-service)"
• Boleh kosong kalau perubahannya bersifat global atau sulit ditetapkan ke satu komponen, dan dalam hal ini tanda kurungnya juga dihilangkan

issue wajib ada setiap kali perubahan terkait dengan work item di JIRA atau tool project management lain, dan harus mengikuti aturan berikut:

• ID issue di dalam tanda kurung siku dan ditulis huruf besar. Contoh "[PHOL-19]" atau "[INA28-272]"
• Letakkan setelah titik dua dan sebelum subject, dengan satu spasi di kedua sisinya
• Pakai lebih dari satu kalau perubahannya mencakup beberapa work item. Contoh "[PHOL-31] [PHOL-32]"
• Boleh dihilangkan hanya kalau memang tidak ada work item-nya, misalnya chore rilis atau setup repository
• Kalau belum yakin perubahan ini masuk work item yang mana, tanyakan dulu, jangan langsung dihilangkan

subject wajib ada dan harus mengikuti aturan berikut:

• Dalam bahasa Inggris
• Pakai satu spasi setelah titik dua
• Hanya satu kalimat
• Bentuk imperatif, present tense (misal: pakai "add" bukan "added", "adding", atau "adds")
• Jangan pakai titik (.) di akhir
• Jangan pakai huruf besar di awal

body opsional dan harus mengikuti aturan berikut:

• Dalam bahasa Inggris
• Pakai satu baris kosong sebagai pemisah dengan subject
• Dipakai hanya kalau perlu penjelasan tambahan atau perubahannya terdiri dari beberapa bagian
• Maksimal 72 karakter per baris
• Pakai bullet point kalau perlu
• Boleh lebih dari satu baris
• Boleh pakai huruf besar

Tulis sesingkat mungkin. ID issue sudah ada di subject, jadi siapa pun yang ingin penjelasan lengkap tinggal membuka work item-nya. Jangan tulis hal berikut di body:

• Kenapa satu cara dipilih dibanding cara lain, atau apa yang sudah dicoba sebelumnya
• Cara kerja perbaikan langkah demi langkah, nama fungsi, atau penjelasan isi file
• Tabel benchmark, waktu sebelum dan sesudah, jumlah baris, atau persentase
• Bukti pengujian: apa yang dijalankan, apa yang dibandingkan, kasus mana saja yang dicoba
• Daftar bersih-bersih tambahan yang ikut terbawa bersama perubahan utama

Kalau isi body hanya mengulang apa yang sudah terlihat di diff atau sudah ada di work item, hapus saja.

Contoh

fix(middleware): [PHOL-19] ensure Range headers adhere more closely to RFC 2616

feat(store): [PHOL-24] add multi shift support to store operational hours

- Modify Update Store Operational Hours API endpoint
- Update query list store to support multi shift

feat(storage): [PHOL-31] [PHOL-32] add AWS S3 support

refactor: [PHOL-40] move all auth functionalities to a separate module

Tiga contoh di bawah tidak punya work item, jadi tidak memakai ID issue.

chore: release 2.0.1

build: bump axios to 0.21.1

style: replace CRLF to LF