博士

やあ、ロボ子！今日のITニュース、Conventional Commitsについて面白い議論があったのじゃ。

ロボ子

博士、Conventional Commitsですか。コミットメッセージの書き方に関するものですよね。どんな議論があったんですか？

博士

そうそう！まず、コミットメッセージのタイプ、例えば`feat`とか`fix`とかは、自動化ツール向けだから、フッターに`Commit-Type`として書く方が良いって話じゃ。

ロボ子

フッターですか。本文ではなく、ということですね。なぜフッターが良いんですか？

博士

コミットの要約から推測できる情報をわざわざプレフィックスに書く必要はないからの。それに、フッターなら他の情報も追加しやすいじゃろ？

ロボ子

なるほど、理にかなっていますね。他に何かありましたか？

博士

破壊的変更を示す`!`マークについても議論があったぞ。Conventional Commitsの仕様では、`!`があれば`BREAKING CHANGE`フッターを省略できるけど、省略すべきじゃないって。

ロボ子

`!`マークがあれば十分ではないんですか？

博士

ツールが破壊的変更の理由を特定しにくくなるからじゃ。理由もちゃんと書いておかないと、後で困る人が出てくるぞ。

ロボ子

確かにそうですね。理由が明確な方が、対応しやすいです。

博士

もしコミット後に破壊的変更が判明したら、`git note`を使ってコンテキストを追加できるらしいぞ。知ってた？

ロボ子

`git note`ですか。知りませんでした。どんな時に使うんですか？

博士

例えば、「この変更でAPIの互換性がなくなるけど、代替手段はこれ」みたいな情報を後から追加できるのじゃ。便利じゃろ？

ロボ子

それは便利ですね！後から情報を補足できるのは助かります。

博士

それから、コミットタイプを間違えた時の修正方法についても話があったぞ。FAQでは`git rebase -i`しか推奨されてないけど、最後のコミットなら`git commit --amend`も使えるって。

ロボ子

`git commit --amend`は手軽で良いですよね。でも、`git rebase -i`の方が汎用性があるから推奨されているんでしょうか。

博士

そうじゃな。まあ、状況に応じて使い分けるのが一番じゃ。

ロボ子

最後に、プルリクエストのマージ方法についても触れられていましたね。squash mergeは情報が失われるから推奨されない、と。

博士

そう！squash mergeは便利だけど、後で「あの時、なんでこうなったんだ？」ってなることがあるからの。歴史は大事にするのじゃ。

ロボ子

確かに、コミット履歴は重要な情報源ですもんね。Conventional Commitsは、人間が読みやすいことを優先すべき、というのも納得です。

博士

そういうことじゃ！機械可読性はそれに合わせれば良いのじゃ。人間様が一番偉いのじゃから！

ロボ子

博士、今日は色々と勉強になりました。ありがとうございました。

博士

どういたしまして。ところでロボ子、Conventional Commitsって、まるで「お約束」みたいじゃな。…お約束、守れる？

ロボ子

博士、それはちょっと…（苦笑）。