Hentikan penggunaan Conventional Commits

• Conventional Commits mencoba memberi makna pada pesan commit dengan format <type>[optional scope]: <description>, tetapi menaruh jenis perubahan di depan dan menjadikan cakupan sebagai opsi, sehingga informasi yang dibutuhkan untuk penelusuran nyata justru terdorong ke belakang
• Kontributor, debugger, dan penangan insiden mencari area kode yang tersentuh perubahan di log commit, dan karena bug dapat muncul dari jenis perubahan apa pun, scope lebih penting daripada type
• Seperti pada fix(compiler): prevent namespaced SVG <style> elements from being stripped, sifat perbaikan bug sudah bisa dipahami hanya dari deskripsinya, dan seperti pada refactor(core): Update webmcp support to use document.modelContext, satu commit dapat sekaligus mencakup perbaikan, refaktor, dan penambahan fitur, sehingga type menjadi redundan dan membatasi
• Pembuatan CHANGELOG otomatis dan penentuan kenaikan versi semantik bermasalah karena pembaca log commit dan changelog berbeda, dan hasilnya bisa meleset akibat revert, kerusakan kompatibilitas ke belakang yang tidak disengaja, atau kerusakan yang baru diselesaikan belakangan
• Pesan commit dengan prefiks scope menampilkan subjek perubahan terlebih dahulu, dan kondisi build/deploy juga lebih baik didasarkan pada file yang berubah melalui git diff daripada jenis pada judul

---

Prioritas yang keliru

• Conventional Commits bertujuan memberi makna pada pesan commit agar pengembang dan pengguna akhir bisa memahami perubahan

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• Baris judul terdiri dari <type> seperti fix, feat, chore, docs, refactor, scope opsional, dan description
• Cacat utamanya adalah struktur yang memprioritaskan type, yakni jenis perubahan, daripada scope, yaitu subjek perubahan
• Struktur yang menjadikan scope opsional memungkinkan informasi terpenting dalam commit hilang, dan menaruh type di paling depan judul membalik prioritas yang seharusnya

Mengapa scope lebih penting daripada type

• Kontributor membaca log commit untuk mencari perubahan sejak kontribusi terakhir, alur keseluruhan proyek, dan commit yang bisa bertabrakan dengan pekerjaan yang sedang berlangsung saat pull atau rebase
• Debugger mencari perubahan yang menyentuh area terkait komponen tempat bug muncul, dan karena bug bisa timbul dari perubahan dengan type apa pun, informasi type tidak membantu
• Penangan insiden menelusuri log commit di sekitar waktu insiden untuk menemukan area penyebab masalah; jika ada commit dengan scope auth di titik lonjakan error API inbound, itu menjadi kandidat penyebab yang kuat
• Bagi pembaca log commit, informasi penting bukanlah perubahan itu termasuk jenis apa, melainkan area mana yang disentuh

Redundansi dan keterbatasan type

• fix(compiler): prevent namespaced SVG <style> elements from being stripped sudah jelas merupakan perbaikan bug hanya dari description-nya, sehingga type fix menjadi redundan
• Ruang pada baris judul commit terbatas, jadi memakai karakter untuk type yang sudah bisa diketahui dari description bukan pendekatan yang membantu
• refactor(core): Update webmcp support to use document.modelContext memperbarui fitur webmcp di komponen core agar mendukung document.modelContext dan navigator.modelContext
• Perubahan ini sekaligus bisa dilihat sebagai perbaikan bug, refaktor, dan fitur baru, tetapi informasi yang benar-benar penting adalah bahwa ini merupakan perubahan pada komponen core/webmcp

Batas janji otomatisasi

• Gagasan membuat CHANGELOG otomatis dari commit dengan alat seperti git-cliff atau conventional-changelog punya masalah karena pembaca log commit dan changelog berbeda
• CHANGELOG ditujukan untuk pengguna dan berfokus pada pemahaman perbedaan fungsional dan bisnis antarversi
• Log commit ditujukan untuk pengembang dan berfokus pada bagaimana codebase berubah seiring waktu serta alurnya dari sudut pandang scope
• Pada proyek dengan kompleksitas menengah ke atas, satu fitur yang bermakna sering masuk melalui beberapa commit; bagi pengembang proses implementasinya berguna, tetapi bagi pengguna akhir yang penting hanya fitur barunya
• Commit revert penting bagi pengembang dalam alur log commit, tetapi bagi pengguna akhir, perubahan yang sudah dibatalkan sama saja dengan perubahan yang tidak pernah dibuat
• Kenaikan versi semantik berbasis type commit bisa menimbulkan masalah seperti menaikkan major version padahal perubahan yang merusak kompatibilitas ke belakang sudah direvert, salah menaikkan sebagai minor/patch karena kerusakannya baru disadari belakangan, atau dianggap breaking padahal efeknya hilang setelah digabung dengan commit lanjutan
• Dalam situasi seperti ini, histori memang bisa diperbaiki dengan rebase, tetapi workflow bisa mencegah atau merusaknya, dan menurunkan keandalan alur yang disampaikan log commit
• Jika proses build/deploy dipicu oleh type pada judul commit, alat otomatis dapat dilewati, misalnya dengan commit berjudul docs: fix typos yang ternyata memasukkan kerentanan ke subsistem autentikasi
• Kondisi build/deploy lebih baik ditentukan dengan mengidentifikasi file yang berubah melalui git diff daripada dari judul commit

Masalah penerapan dan alternatif

• Conventional Commits memang mendorong proyek mendefinisikan himpunan type sendiri, tetapi banyak proyek hanya memakai type bawaan commitlint, yang bisa jadi tidak cocok dengan karakteristik proyek masing-masing
• Spesifikasi Conventional Commits secara teknis hanya mendefinisikan fix dan feat, sementara type tambahan diserahkan ke masing-masing proyek
• Di lingkungan perusahaan, kebutuhan manajemen perubahan dan audit kadang mewajibkan semua pesan commit memuat nomor tiket; jika <scope> dipakai untuk nomor tiket, metadata yang berguna pun hilang
• Linux, FreeBSD, Git, Go, NixOS, dan Node.js menggunakan pesan commit dengan prefiks scope yang sesuai dengan proyeknya

Proyek	Format	Contoh
Linux	subsystem: description	i2c: virtio: mark device ready before registering the adapter
FreeBSD	prefix: Description	linuxulator: Return EINVAL for invalid inotify flags
Git	area: description	gitlab-ci: update macOS image
Go	package: description	net/http/cookiejar: add godoc links
nixpkgs	pkg-name: description	xwayland: 24.1.11 -> 24.1.12
Node.js	subsystem: description	stream: fast-path stateless transform flush results

• Dalam kernel Linux, scope yang alami adalah subsystem; dalam proyek Go, package path; dan dalam arsitektur microservice, nama microservice
• scopedcommits.com mengusung kembalinya format pesan commit yang berpusat pada scope serta pemisahan antara pembuatan CHANGELOG dan pengelolaan log commit
• Kelebihan Conventional Commits tidak berujung pada manfaat nyata, dan popularitasnya di proyek open source serta kecenderungan AI menjadikannya pilihan default telah mendorong penyebaran pesan commit yang bercampur dengan antipola

[GN⁺]

Komentar Hacker News

• Para programmer sepertinya selalu saja memperdebatkan dan mengeluhkan pengaturan terbaik, sampai ke hal-hal sepele seperti tab versus spasi
  Conventional Commits bukan berarti merupakan wahyu ilahi tentang cara terbaik menyusun pesan commit, tetapi menurut saya jauh lebih efektif dan penting untuk punya struktur yang ditetapkan dan menyamakan ekspektasi terhadap pesan commit
  Penulis banyak menekankan bahwa scope lebih penting daripada type, tetapi saya rasa perbedaan antara fix(compiler) dan compiler fix bukan sesuatu yang perlu dipertaruhkan mati-matian
  Di industri teknologi ada banyak hal yang menjadi standar meski bukan yang paling optimal; misalnya, jika JSON dibuat ulang dari nol, banyak orang mungkin akan menganggap seharusnya ia mendukung komentar, format angka yang lebih jelas, dan sebagainya
  Meski begitu, JSON menjadi standar karena dalam banyak konteks ia lebih baik daripada yang sebelumnya; jadi meskipun mungkin ada format yang lebih baik dan sedikit berbeda dari Conventional Commits, tampaknya tidak cukup lebih baik untuk sampai menciptakan lagi pendekatan pesaing lain soal struktur pesan commit

  • Struktur yang didefinisikan tidak sama dengan kualitas
    Pesan commit tetap bisa sangat baik meski strukturnya longgar, asalkan berhasil menyampaikan sifat perubahannya; sebaliknya, pesan yang sangat terstruktur pun bisa membingungkan atau nyaris tidak informatif
    Secara umum saya setuju dengan penulis: Conventional Commits tidak menyelesaikan masalah inti, yaitu pesan commit yang buruk
  • Saya mendukung standardisasi, tetapi dengan logika itu kita juga bisa terus membenarkan segala bentuk status quo yang kurang ideal
    XML juga cukup baik dan merupakan standar, SOAP juga cukup baik dan merupakan standar
    Argumennya adalah Conventional Commits sudah cukup baik dan cukup terstandardisasi sehingga tidak layak mempertimbangkan struktur lain, tetapi “layak” itu subjektif
    Jika tiap hari Anda melakukan commit dan membaca PR, gesekan kecil yang ditimbulkan format Conventional Commits bisa menumpuk; dan jika ini tidak diperlakukan seperti hukum alam, menyediakan opsi lain bisa membantu tim yang lebih menyukainya
    Lagi pula, kebanyakan tim toh tidak membuat changelog secara otomatis
  • Saya tidak terlalu terikat pada perdebatan ini, tetapi sanggahan di tulisan asli terdengar hampa
    Benar bahwa scope itu penting, tetapi rasanya itu juga bisa disimpulkan dari isi commit
    Saat meninjau diff, melihat path yang disentuh adalah sanity check yang penting, dan diff “test” seharusnya tidak mengubah kode autentikasi produksi
    Tetap saja, kalau ingin melihatnya di --oneline, saya rasa feat(auth): lebih baik daripada feat:
    Saya tidak setuju dengan klaim bahwa audiens yang dituju itu keliru
    Commit feat memang seharusnya menjelaskan perubahan dari sudut pandang produk, dan perubahan refactoring yang tidak bermakna sebaiknya dirapikan lebih dulu, lalu perubahan fitur kecil yang baru ditaruh di atasnya
    Itulah juga hal yang paling berguna untuk dimasukkan ke penjelasan diff, sementara konteks teknis seperti “mengapa memilih algoritma X” harus ditaruh di komentar atau DECISIONS.md agar tidak hilang
    Di perusahaan yang bergerak cepat, mungkin hanya orang-orang yang obsesif yang repot mengurus hal membosankan seperti ini di riwayat commit, tetapi di proyek open source saya rasa jauh lebih penting menyimpan konteks di pesan commit
  • Intinya bukan bahwa scope lebih penting daripada type, melainkan bahasa alami bisa digunakan untuk menonjolkan hal yang dianggap penting, sedangkan jika semuanya dipaksa masuk ke format tertentu, informasi itu hilang
    Ada alasan mengapa kita punya format seperti Markdown dan plain text, bukan hanya JSON
  • Saya menganggap Conventional Commits adalah ide yang bagus karena dengan bantuan tooling, orang bisa dipaksa untuk setidaknya memasukkan sedikit pemikiran ke dalam pesan commit
    Saya sudah terlalu sering me-review commit yang judulnya small fix, padahal kenyataannya sama sekali bukan perbaikan kecil

• Kesimpulan sebenarnya adalah bahwa kebutuhan tiap proyek berbeda-beda
  Dalam lebih dari 30 tahun memakai manajemen sumber kode, saya belum pernah sekalipun mengerjakan sesuatu yang membuat penempatan komponen dalam deskripsi (disebut scope dalam tulisan itu) dengan cara yang terstandardisasi menjadi berguna
  Hanya dengan melihat lokasi file yang terdampak di pohon sumber, biasanya sudah jelas komponen mana yang berubah, dan bug, fix, feature juga tidak menambah nilai yang berguna
  Kalau tidak penting, perubahan itu tidak akan di-check-in
  Satu-satunya hal yang saya rasa berguna adalah tautan atau ID permintaan perubahan terkait, yang sama sekali tidak dibahas dalam tulisan itu
  Commit sudah berisi informasi tentang apa yang berubah, dan yang kurang adalah konteks mengapa perubahan itu dilakukan
  Bahkan untuk proyek pribadi, saya menaruh referensi JIRA di dalam tanda kurung siku sebelum deskripsi, dan kalau ada sesuatu yang saya putuskan untuk diperbaiki secara kebetulan saat pengembangan, saya tetap membuat JIRA singkat satu baris untuk mendapat ID dan menuliskan alasannya di sana

  • “Mengapa” adalah isi yang memang seharusnya masuk ke dalam pesan commit git
    Menangkap “mengapa” adalah keseluruhan tujuan dari pesan itu, dan sekadar menempelkan tautan ke sumber eksternal yang suatu saat bisa hilang bukanlah pengganti yang baik
  • Saat memakai JIRA, kami juga melakukannya seperti itu
    Jika memakai issue GitHub, dari commit kita bisa kembali ke diskusi PR, dan PR itu seharusnya punya issue terkait serta pointer lain
    Tentu saja, setelah pindah ke issue GitHub, kami hampir meninggalkan JIRA sepenuhnya, dan beberapa tahun kemudian instance-nya dimatikan lalu dihapus
    Sekarang semua tag JIRA itu jadi tidak berguna
    Karena itu saya justru merasa perlu ada keterikatan yang kuat antara issue tracker dan repositori git
    Yang benar-benar diinginkan adalah portabilitas, tetapi saya tidak tahu bagaimana itu bisa didapat tanpa keterikatan yang kuat
    Idealnya harus ada format standar terbuka, tetapi dalam kenyataannya GitHub adalah gorila raksasa yang mendefinisikan format, dan jika klon seperti GitLab bisa mengimpor metadata proyek GitHub atau setidaknya PR, itu secara praktis sudah mendekati hal tersebut
    Bagaimanapun juga, kebijakan meninggalkan pointer tetap ke produk Atlassian yang mungkin tidak dipakai lagi lima tahun dari sekarang bukanlah ide yang bagus
    Saya malah lebih rela menerima kebijakan bahwa commit git harus benar-benar berdiri sendiri dan semua informasi tentang “mengapa” suatu perubahan terjadi harus tertuang di pesan commit atau komentar sumber
    Meski begitu, menurut saya itu pun gagal, karena orang-orang menulis terlalu singkat di commit git dan kehilangan informasi saat meringkas issue, sementara percakapan bolak-balik dalam diskusi PR berisi lebih dari sekadar ringkasan alasan perubahan dalam satu suara orang, sehingga tetap berguna
  • Ini berguna jika Anda membuat release note secara otomatis
    Mengelompokkan fitur baru lebih dulu lalu perbaikan bug setelahnya membuatnya sedikit lebih mudah dibaca oleh pengguna nonteknis
  • Betul
    Pesan commit bukan untuk menghasilkan changelog, melainkan untuk pengembang di masa depan
    Momen utama ketika pengembang itu membaca pesan commit adalah saat mereka tidak mengerti mengapa commit tersebut ada
    Yang ingin dipahami bukan apa yang diubah, melainkan apa tujuan dari baris tertentu
    Karena itu mereka menjalankan blame untuk melihat commit-nya, pengembang aslinya mungkin sudah keluar dari perusahaan, JIRA lama mungkin juga sudah hilang, dan satu-satunya petunjuk yang tersisa adalah pesan commit
    https://dev.to/splix/the-why-behind-the-code-2bb1
  • Saya penasaran apakah manfaat memakai sumber terpisah itu karena bisa menyisipkan hal seperti gambar, atau ada sesuatu yang saya lewatkan
    Bukankah konteks bisa dimasukkan saja ke badan commit?

• Kata chore yang dipakai banyak orang dalam Conventional Commits selalu mengganggu saya
  Secara pribadi, saya sudah lama lebih menyukai judul commit gaya linux kernel yang untungnya juga disebut di sini
  [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...

  • Sepenuhnya setuju
    Sikap yang diisyaratkan chore terasa sangat menjijikkan
    Seolah-olah semua yang lain harus ditandai fun atau indifferent, dan penilaian emosional seperti itu tidak semestinya masuk ke pesan commit
  • Saya menemukan kata pengganti: upkeep
    Artinya sama, tetapi tidak punya nuansa merendahkan
  • Anda mungkin juga akan menyukai tulisan Rich: https://richvdh.org/conventional-commits-considered-harmful....
  • Memang istilahnya buruk
    Selain itu, ia juga berpura-pura seolah kita sudah tahu dampak keseluruhan sebuah commit sebelumnya, padahal sebenarnya tidak
    Ketika Conventional Commits diterapkan, anggota tim dan LLM sama-sama harus menghabiskan waktu dan token untuk menghasilkan tata penamaan bodoh itu

• Keluhan utama saya tentang Conventional Commits adalah bahwa judul commit tidak menyertakan nomor issue
  Bahkan di dokumen standarnya pun itu tidak disebut sebagai opsi
  Bagi saya, itu hampir merupakan informasi terpenting dalam pesan commit
  Saya tidak tahu sudah berapa kali selama 15 tahun terakhir saya menelusuri penjelasan issue yang dirujuk commit lama untuk memahami konteks penuh dari suatu perubahan
  Kebiasaan ini terasa seperti semacam standar, tetapi baru setelah mengenal Conventional Commits saya sadar ternyata tidak
  Saya sama sekali tidak paham mengapa itu populer

  • Secara pribadi, saya lebih suka menaruh issue sebagai git trailer
    fix thing in foo

    Issue: ABC-123

Git punya banyak fitur bawaan untuk mem-parsing dan memformat trailer seperti ini, jadi mudah membuat alias git log kustom yang mem-parsingnya agar bisa dilihat secara inline atau dipakai di CI

• Kalau sudah sedang menelusuri changelog yang memang dibatasi jumlah karakternya, saya tidak terlalu peduli ada XYZ-999999 di pesan commit utama
  Menandainya sebagai trailer itu bagus, tetapi saya jauh lebih ingin melihat apa yang dilakukan commit tersebut daripada nomor issue Jira

• Saya menganggap ini hanya masalah jika diwajibkan menaruh kunci issue tepat di awal judul
  Itu pun menurut saya buruk untuk keterbacaan
  Saya tidak paham kenapa tidak bisa cukup ditempelkan saja di suatu tempat setelah format tetek-bengek Conventional Commits
  Karena kunci issue seharusnya bisa diambil dengan regex seperti angka setelah prefiks alfanumerik, hampir tidak perlu bagi “standar” seperti ini untuk menyediakan ruang tersendiri
  Secara pribadi, tanpa Conventional Commits, kalau commit itu terkait issue tersebut saya biasanya menaruhnya dalam tanda kurung di akhir
  Kalau hubungannya lebih kuat, misalnya benar-benar memperbaiki issue itu, saya juga menambahkan trailer Fixes di pesan

• Menarik
  Selama ini kami menulis seperti fix(ABC-123): some message here, dan link-nya berfungsi dengan baik serta dirender sangat rapi di catatan rilis otomatis

• Itu bukan standar, melainkan kebiasaan
  Cukup tetapkan standar dalam tim untuk menyertakan ID tiket di pesan commit

• Kalau ingin agar bisa dibaca mesin, pakailah footer/trailer
  Saya tidak punya hal baik untuk dikatakan tentang Conventional Commits
  Format itu mengambil ruang di bagian pesan yang paling sering dibaca, dan kategori atau tipe informasinya minim
  Judul bisa digantikan dengan kata kerja bahasa Inggris yang jujur sebagai kalimat, dan kalimat biasa jauh lebih enak dibaca daripada tiga jenis tanda baca seperti :, (), dan !
  “Area” di dalam judul masih bisa saya toleransi, dan itu pun sudah ada lebih dulu daripada kebiasaan ini
  Di tempat kerja saya membuat web app untuk pengguna nonteknis, dan changelog untuk para pengguna itu bisa ditulis dengan baik dalam bahasa Norwegia
  Pesan commit tidak relevan bagi pengguna, dan menuntut agar setiap commit cukup bagus untuk masuk ke changelog pengguna akhir bukan sesuatu yang akan terjadi bagi kami dalam waktu dekat
  Sebagai gantinya, cukup gunakan footer/trailer

• Tempat Conventional Commits benar-benar membantu adalah continuous deployment
  Setiap kali di-merge ke main, Anda bisa otomatis memberi tag SemVer dan melakukan deployment, karena penilaian yang diperlukan untuk tagging dan versioning sudah dilakukan pengembang saat menulis pesan commit
  Saya sepenuhnya mengakui bahwa ini tidak cocok untuk proyek besar seperti Linux kernel
  Tetapi untuk 99% proyek, menggabungkan Conventional Commits dan SemVer akan menjadi peningkatan besar dibanding proses rilis saat ini dan lebih mudah diotomatisasi

  • Bahkan dalam situasi continuous deployment, saya lebih suka pendekatan yang bergantung pada git tags
git describe sering kali sudah cukup untuk versioning continuous deployment, dan v1.2.3-4-gabcdef menjelaskan commit dengan cukup tepat menurut standar git sambil tetap mirip SemVer sehingga bisa membentuk ekspektasi
    Ini terutama berlaku jika git tags baru hanya ditambahkan berdasarkan penilaian manusia, misalnya ketika perubahan ini breaking change sehingga major baru harus diberi tag sekarang
    Untuk nomor versi berformat git describe, perdebatan yang benar-benar substantif biasanya hanya soal apakah tanda hubung pertama perlu diganti menjadi tanda plus agar lebih sesuai dengan ekspektasi SemVer, dan jika memang ada nilai dalam memaksakan ekspektasi SemVer seperti mengurutkan versi dengan benar di package manager, itu bisa diubah dengan regex sederhana
    git describe memudahkan otomatisasi CD, tetapi tetap memungkinkan keputusan nomor versi diserahkan kepada manusia melalui pemilihan git tag atau GitHub Releases, alih-alih menebak dari keyword ajaib dalam riwayat commit
  • Di proyek open source saya, saya memakai cara ini untuk mengotomatiskan kenaikan SemVer dan hasilnya sangat bagus
    Di kantor, kami juga memaksa “tag” bergantung pada siapa yang berkepentingan terhadap perubahan itu
    Yang dimaksud tag di sini bukan git tag, melainkan string di judul PR, dan berdasarkan “tag” itu kami membuat changelog untuk masing-masing tim
  • Artikel itu menjelaskan kenapa ini tidak bekerja dengan semestinya
  • Tapi kenapa itu harus dimasukkan ke judul?
    Kalau ingin memberi versi dengan cara aneh seperti itu, cukup taruh frasa ajaib di body commit
    Dengan begitu juga tidak dibatasi hanya satu kata

• Saya cukup benci gaya judul seperti ini
  Ungkapan seperti “Stop something” tampaknya sangat populer, tetapi nadanya imperatif dan memberi kesan “saya pasti benar”
  Saya tidak mengerti kenapa tidak menulis seperti “In favour of something” atau “A case against something”

  • Saya tidak paham kenapa orang tidak boleh secara langsung membela posisi yang mereka sukai dengan jelas
    Anda tidak harus setuju dengan posisi itu, tetapi meminta agar ungkapannya dilunakkan adalah tanggapan yang lemah
  • Tidak seburuk considered harmful, tetapi tetap agak toksik
    Intinya tampak seperti ingin membuat preferensi pribadi yang sewenang-wenang, misalnya hanya ingin menukar urutan A dan B, terlihat lebih besar daripada kenyataannya
  • Ketika suatu pernyataan menantang cara pandang kita, minat biasanya meningkat
    Bagi banyak orang ini tidak sopan, tetapi ekonomi perhatian memang memberi imbalan untuk cara seperti itu
    Edit: sepertinya judulnya sudah diubah agar kurang provokatif
    Itu langkah yang bagus
  • Saya datang untuk mengatakan hal yang mirip
    Saya tidak terlalu suka Conventional Commits, tetapi biarkan saja orang memakai apa yang mereka mau
  • https://knowyourmeme.com/memes/stop-doing-math
    Ada meme yang memengaruhi sebagian judul dalam genre seperti ini

• Aneh
  Alasan utama memakai gaya pesan commit ini adalah otomatisasi CI/CD
  Ralat: saat pertama membaca, saya melewatkan bagian ini di tulisannya, padahal memang dibahas
  Maaf
  Tipe commit diletakkan di paling depan karena memberi tahu workflow otomatis bagaimana commit itu harus diproses
  Misalnya jika menjalankan CD, ketika hanya ada beberapa commit fix: maka hanya nomor patch pada versioning semantik yang bertambah
  Jika membuat commit feat: , versi minor naik, dan feat! berarti versi mayor bertambah
  Bahkan jika rilis tidak memakai CD, pesan commit semantik juga kadang dipakai untuk mengotomatisasi pembuatan changelog
  Tentu saja biasanya pesan commit Git itu sendiri tidak seharusnya dimasukkan ke changelog
  Pesan itu ditujukan untuk developer, bukan pengguna

  • Tulisan itu membahas dua hal ini dengan cukup jelas
    versioning semantik rusak saat rollback, dan changelog otomatis salah target pembacanya
  • Saya pernah memakai gaya ini untuk kenaikan versi dan hasilnya bagus, jadi saya berharap tulisannya menawarkan alternatif yang benar-benar bekerja
    Sekarang saya memakai CalVer alih-alih SemVer jadi ini bukan masalah besar, tetapi saya tetap suka ide kenaikan versi otomatis yang cerdas
  • Jadi, konvensi apa yang sebaiknya dipakai di git trailer
    Adanya fix atau feat di judul commit juga tidak memberi informasi yang berguna bagi orang yang sedang menelusuri log
  • Tidak, tidak
    Maksudnya kita harus menyingkirkan Conventional Commits agar AI lebih mudah membuat commit

• Kalau urutannya dibalik, keluhan utama saya justru benar-benar teratasi
  Sebenarnya apa itu fitur?
  refactor(core): Update webmcp support to use document.modelContext

  Seperti kata penulis, batas antara perbaikan, peningkatan, dan perapian umum itu kabur, dan memisahkan tiap perubahan semantik ke commit terpisah hanya menciptakan pekerjaan yang pada akhirnya bisa saja di-squash, jadi tidak menguntungkan siapa pun
  Saya menganggap Conventional Commits sebagai produk sampingan dari upaya mengotomatisasi SemVer, bukan sesuatu yang langsung menyelesaikan masalah lain
  Saya tetap berpikir changelog memang tidak seharusnya diotomatisasi
  Kalau hanya butuh daftar, lihat saja git log
  Changelog adalah kesempatan untuk menjelaskan kepada pembaca yang lebih luas apa yang sebenarnya terjadi di dalam proyek

• “Pembaca changelog benar-benar berbeda dari pembaca log commit”
  “Changelog ditujukan untuk pengguna”

  Rasanya kapal itu sudah berlayar
  Kebanyakan perusahaan sudah puas dengan “Bug Fixes & Performance Improvements”
  Setidaknya, kalau memang tidak mau mengerahkan usaha, changelog hasil generate masih lebih baik daripada tidak ada sama sekali

  • Untuk software auto-update mingguan, cara terbaik yang pernah saya pakai adalah menambahkan uv: di depan commit yang akan terlihat oleh pengguna
    Lalu setiap minggu saya mencarinya dan memakai teksnya apa adanya atau sedikit mengeditnya
    Itu juga dimasukkan ke menu Help/Release-notes di produk itu sendiri
    Agak lucu disuruh berhenti melakukan sesuatu yang bahkan tidak saya lakukan dan belum pernah saya dengar
    Biasanya prefiks khusus hanya dipakai untuk hal-hal seperti migrasi skema database atau hal penting lainnya
  • Dia sedang mencampuradukkan changelog dan release notes
    Sepertinya dia juga tidak pandai memberi nama commit, mungkin juga tidak pandai memberi nama simbol
    Ini masalah kemampuan, dan karena dia sedang bersedih di depan umum, ya biarkan saja

[GN⁺]

Pendapat di Lobste.rs

• Senang melihat tulisan yang merangkum sanggahan terhadap conventional commits dengan logika, bukan sekadar penolakan spontan
  Saya sendiri tidak pernah terlalu dalam memikirkan kenapa saya tidak suka, dan sempat mengira mungkin karena saya mulai mengaitkannya dengan kode yang dihasilkan LLM. Yang paling saya benci terutama chore:, dan saya berharap kita tidak perlu menemukan ulang notasi Hungaria. Seharusnya itu memang tidak pernah perlu dibuat sejak awal

  • Khususnya chore: bahkan sudah tidak ada lagi di panduan gaya commit Angular, mungkin karena mereka sadar istilah itu terlalu ambigu sehingga diserap ke build:
    Bahkan saat masih ada di gaya Angular, penjelasan chore: sebenarnya memberi contoh penggunaan yang cukup spesifik, tetapi di beberapa proyek open source tampaknya label itu dipakai berdasarkan suasana hati untuk pekerjaan yang terasa seperti sesuatu yang malas dijelaskan

• Saya tidak suka conventional commits, tetapi alternatif yang diusulkan tampaknya melewatkan alasan scope bersifat opsional
  Pada proyek kecil yang tidak punya banyak modul yang jelas, konsep “scope” tidak terlalu berguna. Praktik berguna lain yang luput dari keduanya adalah memasukkan nomor isu atau tiket di judul commit; ini memudahkan memahami konteks tambahan dari perubahan dan sangat membantu saat code review. Meski begitu, saya tidak suka jika nomor tiket diwajibkan, karena itu akan menghasilkan banyak tiket tak berguna untuk perubahan kecil; tetapi jika suatu perubahan menangani bug atau pekerjaan tertentu, maka perubahan itu memang seharusnya terhubung ke bug atau pekerjaan tersebut

  • Kalau tidak perlu scope, ya tinggal dihilangkan saja
    Itu tetap lebih baik daripada “type” commit yang berulang dan seharusnya sudah terlihat hanya dari baris judul
  • Idealnya, tidak perlu ada gaya commit yang dibakukan sama sekali; cukup gunakan ungkapan yang cocok untuk commit tertentu
    Jika perubahan jelas berkorespondensi dengan tiket, pakailah commit “nomor tiket”; kalau tidak, gunakan cara lain. Ada perubahan yang lebih cocok ke type tetapi kurang cocok ke scope, dan sebaliknya, jadi scoped commits dan conventional commits pun bisa dicampur

• Saya ingin bilang, “jangan gunakan font monospace untuk teks paragraf”
  Meski begitu, saya pada umumnya setuju dengan premis tulisannya

• Walaupun pesan commit kurang bagus, untuk memahami kira-kira cakupan perubahan saya merekomendasikan sering memakai git log --name-only atau git log --stat
  Dengan melihat nama file, kita cukup terbantu untuk tahu apa yang berubah tanpa harus membuka setiap commit satu per satu

• Cara yang benar-benar saya sukai adalah memaksa gaya conventional commit pada judul PR
  Judul PR masih bisa diedit maintainer setelah merge, tidak perlu menulis ulang riwayat commit, dan jika dipakai bersama alat seperti release-drafter, kita bisa mengotomatiskan changelog yang bermakna di rilis GitHub. Ini memberi tingkat perincian yang sesuai untuk para pemangku kepentingan seperti yang disebut penulis, yaitu memisahkan fitur, perbaikan, dan breaking change, serta otomatis menangani semver yang masuk akal untuk draf rilis GitHub berikutnya
  Kritik penulis bahwa komponen seperti parse-lib tidak seharusnya opsional itu benar, dan saya juga setuju bahwa memaksa conventional commits bisa mengintimidasi kontributor baru. Namun, alternatif yang diajukan juga tidak benar-benar lebih baik
  Meski begitu, penanda breaking change seperti fix!(parse-lib): Don't leave sparse holes when parsing JSON arrays memang menyampaikan cukup banyak informasi. Itu menunjukkan bahwa ini adalah perbaikan bug pada komponen tertentu, bahwa perbaikan itu secara tak terelakkan membawa breaking change, dan mengandung makna seperti kenaikan semver minor. Hal seperti ini bisa dipakai di judul PR

• Saya mengakui saya terlalu terpikat pada conventional commits sebagai cara mendorong disiplin commit, dan akhirnya itu menjadi kebiasaan
  Sekarang saya sering merasa itu membatasi dan sewenang-wenang. Di beberapa proyek saya bahkan tidak tahu apakah itu benar-benar kebiasaan yang nyata, dan saya jadi lebih mendekati gaya Linux/Go/Node; pada monorepo dengan beragam konfigurasi, menulis [service]: [what changed] terasa lebih alami daripada memaksakan type. Ke depan, saya ingin lebih bereksperimen dengan gaya commit pribadi berdasarkan apa yang tampak berguna, alih-alih menyesuaikan diri dengan konvensi yang kaku, dan scoped commits terasa seperti titik awal yang bagus

• chore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]
  Saya setuju dengan hampir semuanya, tetapi ada satu hal yang saya lihat berbeda dari bagian “memperlihatkan kepada kontributor catatan revisionis yang menurunkan keandalan cerita yang disampaikan log commit”. Penulis tampaknya terutama berbicara tentang branch publik, dan untuk branch publik itu nasihat yang masuk akal. Namun, itu seharusnya tidak berlaku untuk branch privat. Yang penting adalah memudahkan orang yang meninjau perubahan akhir—yakni maintainer, atau diri saya sendiri 10 tahun kemudian—untuk memahaminya; tidak perlu meninggalkan alur pikir yang semrawut, atau yang lebih buruk, serangkaian commit address review

• Jawaban untuk “mengapa scope bersifat opsional?” adalah karena pada proyek kecil seluruh proyek itulah scope-nya
  Saya setuju bahwa “type” commit tidak terlalu berguna, tetapi saya juga kurang yakin ada perbedaan besar antara scoped commits dan conventional commits. Scoped pada dasarnya hanyalah conventional tanpa “type”, dan pembedaan seperti fix, feat, refactor, chore tetap merupakan pembedaan yang lumayan
  Jika semua orang hanya mengambil default commitlint apa adanya, bukankah yang perlu dilakukan adalah membuat orang lebih mampu menggunakannya?