2026年5月12日
コミットメッセージは「未来の自分」への手紙
Gitのコミットメッセージ、「修正」「更新」「あとでなおす」だけで済ませていませんか?
3ヶ月後に自分のコードを見返したとき、「このコミットで何を変えたんだっけ?」とならないために、わかりやすいメッセージを書く習慣をつけましょう。
コミットメッセージは「未来の自分」や「一緒に開発するチームメンバー」への手紙です。読む人のことを考えて書くことが大切です。
VS CodeでGitを使う方法と合わせて読むと、実践的に使えます。
コミットメッセージの基本ルール
- 「何をしたか」を簡潔に書く(50文字以内が目安)
- 動詞で始める(「追加」「修正」「削除」「変更」など)
- 「なぜ」は本文に書く(1行目はタイトル、2行目以降は詳細)
- 日本語でOK(チームで英語と決まっていればそれに従う)
- 現在形か過去形で統一する(「追加する」か「追加した」かどちらかに揃える)
💡 メッセージを書く前に考えること
「このコミットは何をするコミットか?」を一言で言えますか?言えなければ、コミットが大きすぎる可能性があります。1つのコミットには1つの変更だけが理想です。
プレフィックス付きテンプレート(おすすめ)
コミットの種類をひと目でわかるようにする「プレフィックス(接頭辞)」をつけると、ログが読みやすくなります。
| プレフィックス | 意味 | 例 |
|---|---|---|
feat: | 新機能追加 | feat: ヘッダーナビゲーションを追加 |
fix: | バグ修正 | fix: スマホでメニューが表示されない問題を修正 |
style: | 見た目の変更 | style: ボタンの色を青に変更 |
docs: | ドキュメント | docs: READMEに使い方を追加 |
refactor: | リファクタリング | refactor: 関数を分割して読みやすく |
test: | テスト追加・修正 | test: ログイン処理のテストを追加 |
chore: | その他(設定など) | chore: パッケージを最新版に更新 |
これは Conventional Commits(コンベンショナルコミット) という、多くの開発現場で使われている標準的な書き方です。
良い例・悪い例を比較しよう
| ❌ 悪い例 | ✅ 良い例 | ポイント |
|---|---|---|
| 修正 | fix: フッターのリンク切れを修正 | 何を修正したかが明確 |
| 更新 | feat: お問い合わせフォームを追加 | 何を追加したかが明確 |
| 変更した | style: ヘッダーの背景色をグラデーションに変更 | どこをどう変えたかが明確 |
| aaa | docs: READMEにインストール手順を追加 | テスト用コミットはすべきでない |
| いろいろ直した | fix: スマホでカードが横にはみ出る問題を修正 | 「いろいろ」は具体的じゃない |
実際にコミットしてみよう
ターミナルでのコミットコマンドも確認しておきましょう。
# 変更したファイルをステージングエリアに追加
git add index.html
# コミットメッセージを付けてコミット
git commit -m "feat: トップページのヘッダーを作成"
# 複数のファイルをまとめてコミット(注意:関係ないファイルは含めない)
git add style.css script.js
git commit -m "style: ボタンのデザインを更新" 詳細なコミットメッセージの書き方
1行目がタイトル、3行目以降が詳細(ボディ)です。2行目は空行にします。
git commit -m "fix: スマホでナビゲーションが表示されない問題を修正
画面幅768px以下でハンバーガーメニューが動作しない問題があった。
JavaScriptのイベントリスナーが正しくない要素に設定されていたため修正。
関連Issue: #12" 実践例(文化祭サイト)
学校の文化祭サイトを作るとして、どんなコミット履歴になるか見てみましょう。
feat: トップページのヒーローセクションを作成feat: 出し物一覧ページを追加fix: スマホでカードが横にはみ出る問題を修正style: フォントをNoto Sans JPに変更docs: README.mdにデプロイ手順を追加feat: お問い合わせフォームを追加fix: フォーム送信後のリダイレクト先を修正
このような履歴なら、数ヶ月後に見ても「いつ何を作ったか」がすぐわかります。
英語でコミットメッセージを書く場合
英語で書く場合は、動詞の原形で始めるのが一般的です。
| 日本語 | 英語(原形) | コミット例 |
|---|---|---|
| 追加する | Add | feat: Add header navigation |
| 修正する | Fix | fix: Fix broken links in footer |
| 更新する | Update | style: Update button colors |
| 削除する | Remove | refactor: Remove unused CSS classes |
| 変更する | Change | chore: Change package versions |
コミットの粒度(大きさ)
コミットは「1つの変更 = 1つのコミット」が理想です。
- ❌ 悪い例:「ヘッダー作成・フッター作成・バグ修正をまとめてコミット」
- ✅ 良い例:「ヘッダー作成」「フッター作成」「バグ修正」を別々にコミット
小さい単位でコミットすると、「あのバグはいつ入り込んだのか」を調べるときや、間違えたときに「1つ前に戻す」ときに便利です。
⚠️ コミットしすぎも問題?
「typo修正」「セミコロン追加」などの1文字の変更を毎回コミットするのも少し多すぎます。「意味のある変更のまとまり」を1コミットにするのがバランスが良いです。
まとめ
- ✅ 「何をしたか」を50文字以内で簡潔に書く
- ✅ プレフィックス(feat/fix/style/docs など)をつける
- ✅ 「修正」「更新」だけのメッセージは避ける
- ✅ 3ヶ月後の自分が読んでわかるように書く
- ✅ 1コミット = 1つの変更が理想
- ✅ 詳細な説明が必要なときは2行目以降に書く