良いコミット説明の書き方

コミット説明のベストプラクティス

説明（サブジェクト行）は、git log --oneline、PRマージコミット、changelog、リリースノートで人々が目にするため、コミットメッセージの最も重要な部分です。よく書かれた説明は、コミット履歴を価値あるドキュメントツールにします。

5つのルール

1. 命令形を使う — "add"、"fix"、"change"（"added"、"fixes"、"changing"ではなく）
2. 小文字で始める — "add feature"（"Add feature"ではなく）
3. 50文字以内に収める — どのツールでも切り詰められないことを保証
4. ピリオドで終わらない — 末尾の句読点は文字を無駄にする
5. 活動ではなく効果を記述する — "add search"（"working on search"ではなく）

命令形テスト

あなたの説明は以下の文を完成させるべきです：

このコミットを適用すると、**[あなたの説明]**します。

• 「このコミットを適用すると、add user authenticationします」 ✔
• 「このコミットを適用すると、added user authenticationします」 ✘
• 「このコミットを適用すると、adding user authenticationします」 ✘

良い例と悪い例

悪い例	問題点	良い例
added new button	過去形	add submit button to form
Fixing stuff	大文字、曖昧	fix null check in validator
update.	ピリオド、曖昧	update retry logic for API calls
WIP	説明がない	add initial login form layout
changes to the user module	活動の記述	extract user validation helpers

50文字の予算

タイプとスコープのプレフィックスを含むと、ヘッダー行全体は以下のようになります：

feat(auth): add two-factor authentication

ヘッダー全体は42文字です。説明"add two-factor authentication"は31文字です。文字予算を計画してください：

• タイプ + コロン + スペース：約6-12文字
• スコープ（使用する場合）：約4-10文字 + 括弧
• 説明：合計50文字までの残り

よく使われるアクション動詞

add       → 新機能
remove    → コードや機能の削除
fix       → バグ修正
update    → 既存動作の変更
refactor  → 動作変更なしの再構築
improve   → 改善
replace   → 実装の入れ替え
extract   → コードを別のユニットに切り出し
rename    → 名前の変更
simplify  → 複雑さの削減