コミットメッセージの書き方

git log で履歴を追うとき、コミットメッセージが雑だと変更の意図がわかりません。

「修正」「更新」だけのメッセージが並ぶログは、どのコミットで何が変わったか判別できず、コードレビューやバグ調査の効率を大きく下げます。

丁寧なメッセージは「なぜこの変更をしたのか」を未来の自分やチームメンバーに伝える手段です。

半年後に git log や git blame で振り返ったとき、良いメッセージが書かれていれば調査時間を大幅に短縮できます。

コミットメッセージの基本構造は3つのパートで構成されます。

1行目は要約（Subject Line）で、変更内容を端的に表します。

50文字以内が推奨です。

2行目は空行で、要約と本文を区切ります。

3行目以降は詳細（Body）で、変更の背景や理由を記述します（任意）。

英語で書く場合、1行目は命令形（"Add", "Fix", "Remove" など）で始めます。

日本語の場合は「〜する」「〜を修正」「〜を追加」のような体言止めが一般的です。

# 良い例
git commit -m "ログインフォームのバリデーションを追加

メールアドレスの形式チェックとパスワード長の
検証を実装。空文字送信時のエラーも修正。"

# 英語の場合
git commit -m "Add validation to login form

Implement email format check and password length
validation. Also fix error on empty submission."

Conventional Commits は type(scope): description の形式でメッセージを標準化する規約です。

type は以下のいずれかを選びます。

• feat

  新機能の追加。

• fix

  バグ修正。

• docs

  ドキュメントのみの変更。

• style

  コードの意味に影響しないフォーマット変更（空白・セミコロンなど）。

• refactor

  バグ修正でも機能追加でもないコード変更。

• test

  テストの追加や修正。

• chore

  ビルドプロセスや補助ツールの変更。

scope は変更対象の範囲を示す任意の項目です（例: auth, ui, api）。

破壊的変更がある場合は type の後に ! を付けます。

# 新機能
git commit -m "feat(auth): ソーシャルログインを追加"

# バグ修正
git commit -m "fix(ui): モーダルが閉じない問題を修正"

# ドキュメント
git commit -m "docs: README にセットアップ手順を追記"

# リファクタリング
git commit -m "refactor(api): ユーザーサービスのエラーハンドリングを整理"

# 破壊的変更
git commit -m "feat(api)!: 認証レスポンスの形式を変更"

• 「修正」「更新」「対応」だけのメッセージ

  何を修正したのか、なぜ更新したのかがわかりません。具体的な対象と理由を書きましょう。

• 巨大なコミットに曖昧なメッセージ

  数十ファイルの変更に「機能改善」とだけ書いてもレビュアーが把握できません。コミットを小さく分割し、それぞれに具体的なメッセージを付けます。

• 関係ない変更を 1 つのコミットに混ぜる

  バグ修正とリファクタリングを混ぜると、後から git revert で一部だけ戻せなくなります。1 つのコミットには 1 つの論理的な変更だけを含めるのが原則です。

# 悪い例
git commit -m "修正"
git commit -m "更新"
git commit -m "いろいろ対応"

# 良い例
git commit -m "fix(cart): 数量が0のとき合計金額がNaNになる問題を修正"
git commit -m "refactor(cart): 合計金額の計算ロジックを関数に抽出"