Ditulisan sebelumnya kita sudah membahas sekilas tentang Git. Kita sudah mempelajari workflow dasar dalam menggunakan Git, baik dari add, commit, stash, dan sebagainya.

Ditulisan ini kita khusus membahas seputar commit, alias menulis pesan commit yang baik...

Namun belum tentu benar.

What's wrong?

Ketika kita bekerja bersama, kita perlu memiliki standar dalam mengerjakan sesuatu. Baik itu standar dari perusahaan, komunitas, ataupun industri.

Agar apa yang kita kerjakan rapih, mudah dimengerti oleh siapapun yang terlibat, dan... Mengikuti standar. Sehingga bisa seragam.

Ketika kita bekerja di industri software, biasanya sudah standar tersendiri seputar gaya penulisan sebuah kode. Baik mengikuti standar dari perusahaan-perusahaan besar, standar yang sudah dibuat oleh bahasa program yang dibuat, apapun.

Sayangnya, di git, belum ada standar khusus untuk 'gaya' penulisan pesan commit. Meskipun ada standar dalam pembuatan pesan commit (seperti subject harus <= 50 karakter), itu hanya standar dalam pembuatan; Bukan penulisan.

Penulisan

Mari kita lihat beberapa gaya penulisan commit yang dilakukan oleh 'perusahaan-perusahaan' besar.

facebook/hermes

Tidak ada standar khusus.

airbnb/epoxy

Sama, tidak ada standar khusus.

netflix/zuul

Netflix sepertinya menggunakan verb sebagai prefix (fix/add/modify/update/dsb) namun masih campur.

google/closure-compiler

Sama menggunakan verb juga, tapi masih campur.

Sekarang kita pindah ke project yang dikembangkan oleh murni komunitas.

SerenityOS/serenity

Sepertinya SerenityOS menggunakan gaya scope [component]: sebagai prefix.

libuv/libuv

libuv sama menggunakan gaya scope juga. Bedanya, kadang scope OS-specific kadang Task-specific.

angular/angular

Ini yang juara! Sekaligus yang ingin kita bahas pada tulisan ini.

Introducing: Commitizen

Commitizen menyebut dirinya sebagai Simple commit conventions for internet citizens.

Sekilas hampir sama seperti gaya yang digunakan oleh angular, ada:

  • feat: Fitur baru
  • fix: Fix bug
  • docs: Perubahan terkait dokumentasi
  • style: Perubahan yang gak berkaitan dengan kode secara langsung (formatting, dsb)
  • refactor: Perubahan yang bukan fitur & fix bug
  • perf: Perubahan terkait dengan peningkatan performa
  • test: Membuat test yang belum ditulis
  • chore: Perubahan seputar build process

Bedanya dengan angular, chore di angular adalah build dan di commitizen tidak ada ci.

Praktik

Ingat contoh yang kita buat disini? Benilah pesan commit yang ada.

Meskipun mungkin lumayan jelas pesannya, mari kita coba bandingkan dengan yang ini:

Gambar diatas hanyalah contoh, terlebih contoh yang kita ambil bukanlah project software. Tapi terlihat lebih rapih, dan mudah dicari. Anggap kita ingin mencari perubahan yang terkait dengan Bab 1 yang mana perubahan itu adalah Style.

Karena kita anggap ketika melakukan formatting, di OS windows terjadi galat karena berbeda EOL.

Simple! Itu kasus sederhana ya, bagaimana bila kita ingin mencari:

  • Kondisi: fix bug
  • Komponen: frontend/auth

Bila pesan commit kita seperti ini:

git commit -am "fix email validation for auth on frontend"

Bandingkan dengan ini:

git commit -am "fix(frontend/auth): email validation"

Sama-sama intuitif, singkat, dan mudah dicari.

Namun, lebih rapih yang kedua. Jangan lupa kasih description jika commit message kamu kurang mudah dimengerti.

Fair, okay?

Kesimpulan

Menulis pesan commit harusnya "ada seninya".

Kita bisa saja menulis pesan asal seperti fix bug, hadeeeh, bismillah kelar dsb yang tidak memiliki konteks yang jelas, terlebih bila hanya bekerja sendiri.

Namun, alangkah lebih bijak ketika kita menulis kode (khususnya di dunia open source) dan memiliki pesan commit yang singkat; Jelas, padat sehingga kita bisa open ke semua orang yang ingin berkontribusi ke project kita.

Dan ya, bisa untuk "meng-edukasi" developer lain juga secara tidak langsung.

Dengan menulis pesan commit menggunakan gaya commitizen, kita membuat history commit kita lebih rapih.

Dan dengan membuat pesan commit yang memiliki deskripsi jelas, kita bisa membuat orang lain mengerti lebih lanjut tentang perubahan yang kita buat, plus bisa "meng-edukasi" mereka juga secara tidak langsung.

Pranala

Pelajari lebih lanjut seputar ini: