Selain menggunakan Semantic Versioning, untuk memudahkan perilisan sebaiknya juga dibarengi dengan menggunakan Semantic Commit Message. Ini adalah sebuah konvensi penulisan struktur pesan commit agar commit history dapat dipahami dengan mudah saat berkolaborasi dengan tim. Penggunaan Semantic Commit Message dapat menyimpulkan tujuan dan efek dari perubahan commit tersebut dengan jelas. Formatnya kurang lebih begini: ${TYPE}: ${SUBJECT}. Atau jika menggunakan Scope jadi begini: ${TYPE}(${SCOPE}): ${SUBJECT}.
Type
Type adalah jenis perubahan yang dilakukan. Type ditulis dengan format huruf kecil semua (lower case). Type ini terdiri dari beberapa jenis, di antaranya sebagai berikut:
feat
“feat” adalah singkatan dari feature yang artinya adalah penambahan fitur baru. Feature ini ga hanya tentang penambahan modul baru saja. Setiap ada perubahan fungsional ataupun behavior dari fitur yang ada saat ini juga termasuk. Contohnya feat: sort customers by registered date.
fix
Sesuai namanya, “fix” adalah perubahan code terkait perbaikan bugs. Setiap fitur yang ada saat ini yang ga berjalan sesuai requirement yang diinginkan termasuk ke dalam jenis ini. Contohnya fix: handle invalid discount calculation.
perf
“perf” adalah singkatan dari performance. Ini digunakan saat meningkatkan performa aplikasi tanpa perubahan terkait fungsional aplikasi dari fitur yang sudah ada. Efek sampingnya di sini hanyalah performa tanpa ada efek samping lain. Contohnya: perf: optimize query on user search.
refactor
“refactor” adalah melakukan perubahan code tanpa ada efek samping apa pun. Biasanya untuk merapikan code agar lebih readable dan maintainable. Ekspektasinya ga ada perubahan fungsional atau behavior terhadap fitur yang ada saat ini. Contohnya: refactor: rename variables.
test
“test” adalah melakukan perubahan code terkait testing saja. Termasuk penambahan test case, fixing test, menghapus test, refactor test, atau apa pun terkait testing. Contohnya: test: add more test cases on product order approval.
style
“style” adalah melakukan formatting terhadap code-style yang ga sesuai kesepakatan tim. Misalnya pada sebuah tim disepakati bahwa code-nya akan ditulis menggunakan tab 4 spasi, tapi ada code yang menggunakan tab 8 spasi. Atau pada code JavaScript disepakati bahwa tiap akhir statement wajib menggunakan ;, tapi ada code yang ga ada ;. Contohnya: style: add missing semicolon.
docs
“docs” merupakan singkatan dari documentation. Scope-nya hanya seputar dokumentasi. Misalnya terkait Readme, License, Guidelines, dan sebagainya. Contohnya: docs: update installation steps on Readme.
chore
“chore” ini scope-nya terkait maintenance aplikasi. Yang paling sering dilakukan adalah saat bump versi dependency atau menambahkan debug logging. Contohnya: chore: bump hibernate version to 6.0.2.Final.
build
“build” ini scope-nya hanya sebatas perubahan terhadap build system. Misalnya saat menggunakan Makefile, Webpack, Docker, atau build tools lainnya. Bisa juga pada perubahan arguments saat build aplikasi. Perubahannya hanya terkait syntax pada build tools yang digunakan. Contohnya: build: update Makefile build config.
ci
Ini cukup jelas, “ci” scope-nya hanya terkait perubahan pada config CI/CD pipeline. Contohnya: ci: add new workflow.
revert
Ini juga cukup jelas, “revert” ini tentang pembatalan commit sebelumnya, apa pun jenis commitnya. Contohnya: revert: remove experimental features.
Scope
Bagian kedua adalah Scope, yaitu nama modul atau komponen yang terdampak terkait commit yang dilakukan. Scope ditulis di dalam kurung setelah Type dan sebelum karakter “:” dengan huruf kecil semua. Scope ini sebenarnya ga wajib, boleh ditulis atau tidak. Ini tergantung dari kesepakatan tim aja, mau pakai Scope atau tidak. Jika pakai Scope, maka penulisannya jadi begini: fix(inventory): race condition on stock update.
Subject
Bagian terakhir adalah Subject. Ini ditulis setelah karakter “:” dengan jarak satu spasi. Ini isinya pesan singkat terkait apa yang dilakukan pada commit tersebut. Pesannya harus singkat dan padat. Best practice-nya jangan lebih dari 50 karakter dan jangan sampai ada breaking line, jadi satu kalimat aja isinya. Penulisannya berupa huruf kecil semua, kecuali ada istilah yang memang harus ditulis menggunakan huruf besar.
Body
Format yang umum sebenarnya ${TYPE}: ${SUBJECT} atau ${TYPE}(${SCOPE}): ${SUBJECT}, tapi ada kalanya kondisi di mana perlu dijelaskan lebih detail lagi isi dari commit tersebut. Untuk hal ini, maka boleh ditambahkan Body di dalamnya untuk menjelaskan detailnya. Formatnya jadi begini:
${TYPE}(${SCOPE}): ${SUBJECT}
${BODY}Body ditulis setelah subject dan baris kosong di bawahnya. Inilah yang menjelaskan lebih detail terkait commit yang dilakukan jika memang diperlukan. Body ditulis dengan sentence case, yaitu sesuai tata bahasa, seperti diawali huruf besar, tiap kalimat diakhiri titik, penggunaan huruf besar sesuai ketentuan bahasa, penggunaan tanda baca sesuai tempatnya, dan kaidah bahasa lainnya. Best practice-nya, Body ditulis maksimal 100 karakter. Contohnya seperti ini:
fix(customer): correct customer list UI overflow on mobile
It affects small width orientation devices. No impacts on larger devices.Footer
Ini juga optional. Footer isinya pesan khusus terkait reference issue, breaking changes warning, atau terkait co-authors. Reference issue ini bisa dari ID Jira Issue, Github Issues, atau tools sejenis yang digunakan sebagai project tracking system dengan hashtag #. Ini ditulis setelah baris kosong di bawah Subject atau Body jika menggunakan Body. Formatnya begini:
${TYPE}(${SCOPE}): ${SUBJECT}
${BODY}
${FOOTER}Contohnya seperti ini:
fix(customer): correct customer list UI overflow on mobile
It affects small width orientation devices. No impacts on larger devices.
#JIRA-0123 #FIN-XYZVerdict
Dengan Semantic Commit Messages kita memberikan kejelasan terkait perubahan apa yang dilakukan oleh suatu commit. Ini dapat mempermudah review sebelum perilisan karena pesannya ditulis dengan format konsisten. Pada commit history jadi terdapat semacam dokumentasi kecil yang mudah dipahami. Format yang paling umum digunakan adalah format menggunakan Type dan Subject. Sedangkan Scope, Body, dan Footer hanya digunakan jika memang diperlukan atau tergantung kesepakatan bersama tim. Oh ya, sebaiknya jangan menggabungkan Type commit yang tidak berkaitan karena itu justru dapat memperburuk readability. Sebaliknya, misalkan pada suatu commit terdapat lebih dari satu Type yang saling berhubungan dan porsinya ga terlalu besar, maka dapat digabungkan. Misalnya dalam sebuah commit terdapat penambahan fitur beserta unit test-nya, maka dapat ditulis feat saja tanpa perlu dipisah commit-nya. Atau misalkan pada saat bug fixing juga terdapat sedikit refactor, maka dapat ditulis fix saja tanpa perlu dipisah refactoring-nya. Kecuali jika porsi refactor-nya cukup besar saat fixing, maka dalam hal ini sebaiknya commit dipisah saja.