Ketika seorang pengembang melihat kembali sesuatu yang telah dikerjakannya enam bulan lalu, seringkali dia tidak memahami mengapa dia membuat commit tertentu, dan satu-satunya alasannya adalah karena dia tidak mengikuti cara yang benar dalam menulis pesan commit.
\ Ada standar pesan commit yang dipraktikkan oleh pengembang di seluruh dunia, dan sangat baik untuk mengikuti standar populer sehingga ketika Anda kembali setelah waktu yang cukup lama atau orang lain melihat pesan commit Anda, mereka tidak akan terlihat memalukan!
\
\ Tim harus terlebih dahulu memutuskan konvensi pesan commit yang menentukan riwayat kontrol versi dari produk yang mereka bangun.
\ Pesan commit Git yang bagus harus memiliki gaya, konten, dan metadata yang tepat.
\ Commit Git yang dikenal mengikuti konvensi ini:
<type>(<scope>): <message>
\ <type> bisa berupa salah satu dari berikut ini:
feat untuk fitur baru.refactor untuk refaktorisasi kode produksi, misalnya, mengganti nama fungsi.docs untuk perubahan pada dokumentasi.fix untuk perbaikan bug bagi pengguna.perf untuk peningkatan kinerja.style untuk perubahan format, titik koma yang hilang, dll.test untuk menambahkan tes yang hilang, refaktorisasi tes.build untuk memperbarui konfigurasi build, alat pengembangan, atau perubahan lain yang tidak relevan bagi pengguna.\ Anda juga dapat menambahkan jenis kustom Anda sendiri, tergantung pada standar yang diikuti tim Anda. Standar di atas diikuti oleh tim ESLint. Anda dapat memeriksa pesan commit mereka di sini.
\ Scope bersifat opsional, dan bagian pesan harus mencakup pernyataan satu baris, tidak lebih dari 72 karakter, untuk merangkum tujuan commit tersebut.
\ Banyak pengembang juga menggunakan pesan sebagai baris subjek dan menambahkan body juga; itu pada dasarnya adalah deskripsi dari commit, tetapi pesan commit satu baris lebih disukai selama Anda dapat memahami konteksnya (apa dan mengapa commit). Jika commit memerlukan deskripsi yang lebih detail yang tidak dapat dijelaskan dalam satu baris, body commit selalu diperlukan.
\ Anda juga dapat menggunakan alat seperti Glitter atau Commitizen untuk menstandarisasi pesan commit Anda.
\ Tidak hanya itu, Anda mungkin juga bertanya-tanya apakah ada alat yang memeriksa pesan commit Anda dan menampilkan kesalahan jika tidak mengikuti pedoman. Commit lint adalah salah satunya. Ini membantu tim Anda mematuhi konvensi commit.
\ Seringkali, para ahli industri menggunakan tiket JIRA atau Click Up mereka sebagai pesan commit sehingga semuanya dapat dihubungkan atau dilacak kembali kapan saja, dan basis kode tetap dapat dipelihara untuk pengembang di masa depan.
\ Beberapa tim juga suka menambahkan emoji ke pesan commit mereka. Saya telah mengumpulkan daftar emoji dan makna masing-masing. Anda dapat melihatnya di sini.
\ Pada akhirnya, hal penting adalah bahwa pesan commit Anda harus bermakna dan tidak membingungkan rekan pengembang Anda atau pengembang masa depan tentang perubahan tertentu.
\ Jika Anda ingin mempelajari lebih lanjut tentang conventional commits, semantic commits, atau praktik yang diikuti industri, berikut adalah beberapa sumber daya untuk Anda:
\


