commit-messages

コミットメッセージ

意図がひと目で伝わる、明確で簡潔なコミットメッセージを書くためのガイドラインです。

使用する場面

• 新しい変更のコミットメッセージを書くとき
• コミットをスカッシュまたはリベースするとき
• コミットメッセージの明確さをレビューするとき

対象外： タグのメッセージ、自動ツールによるマージコミットのメッセージ、変更履歴のエントリ。

手順

1. 簡潔な件名を書く — ほとんどの人が目にするのは最初の行です：

   • 最大の目安は160文字です。短いほどよいでしょう
   • 命令形を使います。「Add feature」のようにし、「Added」や「Adds」は使いません
   • 先頭は大文字にし、末尾にピリオドは付けません
   • 作業の手順ではなく、変更内容を要約します

2. 件名と本文の間に空行を入れる — ツールが正しく解析するために必須です。件名だけで十分な場合は、本文を省略します。

3. 背景説明が必要な場合は本文を書く — 何をではなく、なぜかを説明します：

   • 1行あたり約72文字で折り返します
   • 変更の動機を示し、制約や判断について説明します
   • Fixes #123 または Refs #456 で課題を参照します

4. 1つのコミットにつき、論理的な変更は1つにする — 変更を説明するのに「and」が必要なら、おそらく2つのコミットに分けるべきです。

含める内容

• 大まかな変更内容
• 変更の理由（特に本文）
• 該当する場合は、破壊的変更や移行に関する注意事項
• 該当する場合は、課題への参照

含めない内容

• ファイル一覧 — git diff と git show で確認できます
• 曖昧な説明 — 「fix bug」「update stuff」「WIP」
• 無関係な複数の変更 — 別々のコミットに分けます
• 実装の詳細 — 差分を見れば方法がわかります。メッセージでは理由を説明します

よくある落とし穴

• 曖昧な件名： 「fix bug」では読者に何も伝わりません。バグや修正内容を具体的に示します。
• 過去形： 「Added feature」は日記のように読めます。命令形の「Add feature」を使います。
• 件名が長すぎる： 160文字を超えると、多くの表示で途中までしか表示されません。ざっと読める長さに保ちます。
• 件名の後に空行がない： ツール（git log --oneline、GitHub、変更履歴）で問題が発生します。
• 巨大なコミット： メッセージが小説のようなら、コミットが大きすぎます。分割します。
• メッセージ内のコメントアウトされたコード： 差分やコードを本文に貼り付けないでください。

確認

コミットメッセージを書いた後、次の点を確認します：

• 件名が160文字未満で、変更内容を要約している
• 命令形（「Fix」「Add」「Update」）を使っている
• 本文がある場合、件名との間に空行がある
• 本文で何をではなくなぜかを説明している
• 1つのコミットにつき、論理的な変更が1つである

簡単なチェックリスト：

Is the subject under 160 characters?
Does it use imperative mood?
Is there a blank line after the subject?
Does the body explain why (if present)?
Could this commit be split into smaller ones?