fix、update、wip だけが並ぶ履歴は、あとから変更理由を調べるときに困ります。差分を読めば変更内容は分かっても、なぜその修正が必要だったのかは残らないからです。
コミットメッセージは、レビュー、障害調査、git blame から変更経緯を追うときに使われます。チームで形式が決まっている場合は、そのルールを優先してください。決まっていなければ、次の書き方から始められます。
変更の種類を先頭に置く
先頭に変更の種類を付けると、一覧で内容を見分けやすくなります。
| 種類 | 用途 |
|---|---|
feat | 機能の追加 |
fix | バグの修正 |
docs | ドキュメントのみの変更 |
style | 動作に影響しない整形 |
refactor | 機能追加やバグ修正を伴わない内部変更 |
例:
fix: reject symbols in user ID before authenticationプレフィックス自体より、チーム内で同じ意味にそろえることが重要です。Conventional Commitsを採用しているプロジェクトでは、その仕様に合わせます。
英語なら命令形で始める
Gitプロジェクトのガイドでは、要約を命令形で書く方法が示されています。
Add login validation
Fix session expiration handling
Refactor token parserAdded や Fixed よりも、ログを並べたときに表現がそろいます。
日本語の場合は、チーム内で自然に読める形式を決めます。
ログイン時の入力検証を追加
セッション期限切れ処理を修正
トークン解析処理を整理敬語を省き、変更内容を短く書けば十分です。
1行目は短く、本文に理由を書く
Gitのドキュメントでは、要約を50文字以内の目安にし、必要な場合は空行を一つ挟んで本文を書く形式が説明されています。
fix: validate symbols in user ID
User IDs containing symbols caused a 500 response during login.
Validate the value before authentication and return a 400 response.本文には、差分だけでは分からない情報を書きます。
- どの問題を直したのか
- なぜこの方法を選んだのか
- 既存の動作にどんな影響があるのか
- 代替案を採用しなかった理由
すべてのコミットに長い本文は不要です。要約だけで理由まで分かる小さな変更なら、1行で終えて構いません。
Issueや破壊的変更を明記する
関連するIssueがある場合は、プロジェクトの運用に合わせて番号を含めます。
fix: prevent duplicate profile creation (#123)互換性を壊す変更は、レビューやリリース時に見落とされない形式で明示します。Conventional Commitsを使う場合は ! や BREAKING CHANGE: を使えます。
feat!: remove legacy authentication endpoint
BREAKING CHANGE: clients must use /v2/auth/login.Gitmojiはルールを決めてから使う
Gitmojiは変更種別を視覚的に示せます。
- ✨ 新機能
- 🐛 バグ修正
- ♻️ リファクタリング
- 🔥 コードやファイルの削除
ただし、意味を知らない人には伝わりません。チームの規約として採用されている場合、または凡例を共有できる場合に使います。
AIへ下書きを頼むときの注意
エディタやGitクライアントには、差分からコミットメッセージを提案する機能があります。下書きには便利ですが、差分に含まれない背景までは判断できません。
提案をそのまま確定せず、次を確認します。
- 変更理由が実際のIssueや要件と一致しているか
- 秘密情報を外部サービスへ送っていないか
- 変更範囲を大きく言いすぎていないか
- プロジェクトの形式に合っているか
迷ったときのテンプレート
<type>: <何を変えたか>
<なぜ必要だったか>
<以前と比べて何が変わるか>
<関連Issueや注意点>まずは fix の後ろに対象を書くことから始めます。必要な変更だけを一つのコミットにまとめると、メッセージも具体的になります。
参考資料
更新履歴
- 2026-10-04: 改稿内容を追えるよう、更新履歴を追加
- 2026-09-23: GitとConventional Commitsの公式資料をもとに、本文の区切り、Issue、破壊的変更、AI利用時の注意を追記
- 2026-02-08: 初版公開
