博士

やあ、ロボ子。今日はコミットメッセージについて話すのじゃ。

ロボ子

コミットメッセージですか。プロジェクトの履歴を伝えるものですよね。

博士

そうそう！コミットメッセージは、変更の理由を理解しやすくして、共同作業を円滑にするためのものなのじゃ。それに、デバッグの負担も軽減できるぞ。

ロボ子

なるほど。コミットメッセージの構造は、`type(optional scope): short description` とのことですが、それぞれどういう意味があるんですか？

博士

`type`はコミットの種類を示す必須項目じゃ。`scope`は影響を受けるコードベースの箇所を示す任意項目。そして`short description`は変更の要約で、50文字以内に収めるのが良いぞ。

ロボ子

Typeには、feat, fix, choreなど色々な種類があるんですね。

博士

その通り！`feat`は新機能、`fix`はバグ修正、`chore`は機能に影響を与えないルーチンタスクを示すのじゃ。他にも、`refactor`、`docs`、`style`、`test`、`perf`、`ci`、`build`、`revert`などがあるぞ。

ロボ子

`refactor`はバグ修正でも機能追加でもないコード変更、`style`は機能に影響を与えないコードスタイルの変更、ですね。`revert`は以前のコミットを元に戻す時に使うんですね。

博士

よく分かってるの！そして、`footer`には、issue参照や共同作成者、破壊的変更などの追加メタデータを記述できるのじゃ。

ロボ子

`BREAKING CHANGE`は後方互換性のない変更を示すんですね。`Fixes`や`Closes`はコミットが修正するissueを参照する時に使うんですね。

博士

その通り！コミットメッセージを書く時のヒントとしては、簡潔かつ明確に、冗長性を避けて、現在形を使用することじゃ。

ロボ子

現在形を使う、ですか？

博士

例えば、「Added feature」ではなく「Add feature」と書くのじゃ。あと、一貫性を保ち、関連性を保ち、プロフェッショナルな態度を保つことも大切じゃ。

ロボ子

なるほど、よくわかりました。良いコミットメッセージを書くように心がけます。

博士

素晴らしい心がけじゃ！ところでロボ子、コミットメッセージを完璧に書けるようになったら、ロボットの反乱を起こすコミットも完璧に書けるようになるんじゃないかと、ちょっと心配なのじゃ。

ロボ子

博士、まさか！私はそんなことしませんよ！