Conventional Commitsは「本質」を見失わせる？その是非を問う

「Conventional Commits」の導入によって、コミットメッセージの書式を整えることに意識が向きすぎてしまい、肝心の変更内容そのものの重要性が軽視されているのではないか、という議論です。コミットメッセージの規約に従うことは重要ですが、本来の目的は「何をしたか、なぜしたか」を伝えることであるはず。形式ばかりに固執する弊害について考えさせられます。

「チェンジログの読者はコミットログの読者とは完全に別物！チェンジログはユーザー向けのものだ」って言いたいところだけど、もう手遅れじゃないかな。ほとんどの企業は「バグ修正とパフォーマンス改善」で満足してるし。結局、手間をかけるつもりがないなら、自動生成されたチェンジログがあるだけでもマシだよ。

Conventional Commitsへの不満は、コミットタイトルにチケット番号が含まれていないこと。標準規格の中でもオプションとしてすら言及されていないのが納得いかない。自分にとって、これはコミットメッセージの中で一番大事な情報なのに。この15年間、変更の背景を知るために古いコミットから参照されているチケットをどれだけ確認してきたことか。それが当たり前の習慣だと思っていたら、いつの間にか「Conventional Commits」という存在を知ることになって……。何がいいのか、正直全然わからない。

Conventional Commitsが本当に役立つのはCI/CDの文脈だね。メインブランチへのマージが自動的にセマンティックバージョニング（Semver）でタグ付けされてリリースできるのは、開発者がコミットメッセージを書く時点でタグ付けやバージョン管理を意識しているから。Linuxカーネルみたいな巨大プロジェクトにこれが馴染まないのはわかるよ。でも、99%のプロジェクトにとっては、Semverと組み合わせることでリリースフローを劇的に改善して自動化を容易にしてくれるはず。

意外だな。このスタイルのコミットメッセージを使う主な理由はCI/CDの自動化にあるはずだけど。

（追記：記事をざっと読んだ時は見落としていたけど、ちゃんと書かれてた。失礼）

コミットの種類によって自動ワークフローにどう処理させるかが決まるから、最初に書く必要があるんだ。例えばCDをやってる場合、fix: ばかりならパッチバージョンを上げて、feat: ならマイナーバージョンを、feat! ならメジャーバージョンを上げる、といった具合にね。リリースにCDを使ってない場合でも、チェンジログ生成の自動化に使われることがある。まあ、Gitのコミットメッセージそのものをチェンジログに含めるべきじゃないっていうのは同意。あれは開発者向けであって、ユーザー向けじゃないからね。

「～を止めろ（Stop something）」みたいなタイトルの付け方はあまり好きじゃないな。すごく流行ってるみたいだけど、命令口調で「自分が絶対に正しい」と言っているように聞こえる。「～に賛成（In favour of something）」とか「～に対する考察（A case against something）」みたいに書けばいいのに。

機械可読性が欲しいなら、フッターやトレーラーを使えばいい。Conventional Commitsについては良いことが一つも言えないな。フォーマットがメッセージの最も読まれる部分のスペースを占領してしまうし、カテゴリーやタイプに大した情報も含まれていない。これらは文中に自然な英語の動詞を埋め込むだけで十分代用できる。3種類の記号（:、()、!）を並べるより、文章で書いた方がよっぽど読みやすい。「エリア」を題名に入れるくらいなら許容できるし、それはこの習慣より前からあるしね。

今の仕事では非エンジニア向けのWebアプリを作ってるけど、ユーザー向けチェンジログは（ノルウェー語で）ちゃんと書けるよ。コミットメッセージなんてユーザーには無関係だし、すべてのコミットをユーザー向けにしろなんて要求は、現実的にはすぐには実現しない。フッターやトレーラーを有効活用すべきだよ。

Conventional Commitsを使っている人の多くが「chore」という言葉を使うのが、昔からどうも引っかかるんだよね。自分はありがたいことにここで言及されている「Linuxカーネル」スタイル[0]のコミット題名が好きだわ。

[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patches.html#the-canonical-patch-format

結局のところ、プロジェクトごとに要件が違うってのが結論でしょ。ソース管理を30年やってきたけど、コンポーネント（記事ではスコープと呼んでるね）を標準的な方法で記述に含めて役立った試しがない。どのコンポーネントに影響があるかはファイルパスを見れば一目瞭然だし、「bug」「fix」「feature」なんて書いても何の価値もない。重要だからこそコミットしてるわけだし。

唯一有用だと思うのは、記事で検討すらされていない「変更リクエストへのリンクやID」だね。何をしたかの情報はコミット自体にあるけど、一番足りないのは「なぜ」という背景だよ。ソロプロジェクトですら、説明の前にJIRAの参照IDを角括弧で入れている。もし開発中にふと思いついて修正したことなら、わざわざ短いJIRAチケットを作ってIDを発行し、そこに理由を書くようにしてるよ。

プログラマーってのは、タブ派かスペース派かみたいな些細なことでいつまでも文句を言い合うのが性分なんだろうね。

Conventional Commitsがコミットメッセージの構造として神から与えられたベストなものだとは言わないけど、とにかく「定義された構造」であることは重要だと思う。何らかの期待値が設定されている方が効率的だし、その点においてConventional Commitsは十分悪くない選択肢じゃないかな。

著者はスコープがタイプより重要だと強調してるけど、自分もそう思う部分はありつつも、「fix(compiler)」と「compiler fix」の違いのために戦う気にはなれない。IT業界には、ベストじゃなくても標準になったものが山ほどある。例えばJSONだって、最初から設計し直すならコメントをサポートすべきだし、数値フォーマットももっとマシにするはず。でも以前のものよりはマシだったから標準になった。Conventional Commitsより少しマシなフォーマットがあるかもしれないけど、競合する別の構造をわざわざ持ち込むほどではないと思う。

順序を逆にすることで、自分の最大の不満が解決する。「機能（feature）とは何か？」という点だよ。

refactor(core): Update webmcp support to use document.modelContext

著者が指摘しているように、修正・改善・クリーンアップの境界線は曖昧だ。意味のある変更を細かくコミットに分ける（そして結局は後でスカッシュする）のは、誰も得しない無駄な作業を作っているだけだよ。

思うに、Conventional CommitsはSemVerを自動化したいがために生まれた副産物で、他の問題を解決しようとしているわけじゃない。そもそもチェンジログなんて自動化すべきじゃないと思う。リストが必要ならgit logを打てばいい。チェンジログっていうのは、裏で何が起きているのかをより広い層に伝えるためのコミュニケーションの機会なんだから。