複数行の本文を持つコミット

複数行の本文を持つConventional Commitの構造化方法。空行ルール、本文行の長さ制限、詳細な説明を追加するタイミングを学びます。

Best Practices

詳細な説明

コミットに本文を追加する

コミット本文は、件名行に収まらない追加のコンテキストを提供します。変更が何をしたかだけでなく、なぜ行われたかを説明します。

構造

fix(cache): prevent stale data after TTL expiration

The cache was returning stale entries when the TTL expired
during a concurrent read. The fix adds a lock-free check
of the expiration timestamp before returning cached values.

This was causing intermittent 500 errors on the /api/users
endpoint when cache entries expired under high load.

本文のルール

  1. 空行:件名と本文の間に空行が必要です。これがないと、Gitはメッセージ全体を件名として扱います。
  2. 行の長さ:本文の行は100文字で折り返すべきです。リンターはこの制限を超える行に対して警告を発します。
  3. 内容:変更の動機、解決する問題、検討したトレードオフや代替案を説明します。
  4. フォーマット:本文では箇条書き、番号付きリスト、コードブロックを使用できます。

本文を追加するタイミング

すべてのコミットに本文が必要なわけではありません。以下の場合に追加してください:

  • 明らかでないバグを修正する場合(根本原因を説明)
  • アプローチが直感に反する場合(なぜこの解決策を選んだか説明)
  • 変更に副作用がある場合(文書化する)
  • 前のコミットを取り消す場合(元のコミットを参照)
  • 他の開発者が依存する動作を変更する場合

本文とプルリクエストの説明

コミット本文はGit履歴に永続的に存在します。PR説明はホスティングプラットフォーム(GitHub、GitLab)に存在します。ホスティングプラットフォームにアクセスできなくてもGitログを読む人がアクセスできるべき情報にはコミット本文を使用してください。

行の折り返し

ほとんどのターミナルは1行あたり80〜120文字を表示します。本文テキストを72〜100文字で折り返すと、git log出力で水平スクロールなしに読みやすくなります。

ユースケース

複雑なバグの修正、アーキテクチャの決定の導入、または明らかでない影響があるコミットに複数行の本文を追加します。本文はGit履歴に永続的なコンテキストを提供し、将来の開発者が変更が行われた理由を理解するのに役立ちます。

試してみる — Conventional Commits Linter

フルツールを開く