はじめに
「コミットメッセージは『修正』で伝わるでしょ」
え、まだコミットに『修正』しか書いてないんですか？これ、3ヶ月後の自分も含めて誰も何を直したかわかりません
この記事で解決すること
動画「【恐怖】Gitコミットメッセージが「修正」」の補足記事です。
動画では時間の都合で触れられなかった詳細を解説します。
問題：なぜこれが危険なのか
え、まだコミットに『修正』しか書いてないんですか？これ、3ヶ月後の自分も含めて誰も何を直したかわかりません
解決策：明日から使えるベストプラクティス
Conventional Commits形式（fix: ○○、feat: ○○）でメッセージを書く
以下は、動画やブログでそのまま紹介できるように「悪い例 → 良い例 → ベストプラクティス」の流れでまとめた具体例です。
問題：なぜこれが危険なのか
え、まだコミットに「修正」しか書いてないんですか？
これ、3ヶ月後の自分も含めて誰も何を直したかわかりません。
例えば、Gitの履歴がこんな状態だったとします。
$ git log --oneline
8b5d3f2 修正
9d7a120 修正
2c3fa11 修正
5ab12ef 修正
これでは...
- バグ修正なのか
- 新機能なのか
- リファクタリングなのか
- ドキュメント更新なのか
誰にも判断できません。
障害対応時にも
「ログイン画面を変更したコミットはどれ？」
となっても探すのが非常に困難になります。
悪い例
git add .
git commit -m "修正"
または
git commit -m "update"
git commit -m "fix"
git commit -m "変更"
これらは内容が全く分かりません。
解決策：明日から使えるベストプラクティス
Conventional Commits を使う
<type>: <内容>
例えば
git commit -m "fix: ログイン失敗時のNullPointerExceptionを修正"
git commit -m "feat: パスワード再設定機能を追加"
git commit -m "docs: READMEにセットアップ手順を追記"
git commit -m "refactor: UserServiceの責務を分離"
よく使うtype一覧
| Type | 用途 | 例 |
|---|---|---|
feat |
新機能 | feat: ユーザー検索機能を追加 |
fix |
バグ修正 | fix: APIタイムアウトを修正 |
docs |
ドキュメント | docs: インストール手順を更新 |
style |
フォーマットのみ | style: インデントを統一 |
refactor |
リファクタリング | refactor: 認証処理を分離 |
test |
テスト | test: UserServiceの単体テスト追加 |
perf |
高速化 | perf: キャッシュを追加して検索速度改善 |
chore |
雑務・設定変更 | chore: ESLint設定を更新 |
実際の開発例
悪い履歴
修正
修正
修正
修正
修正
何をしたのか分かりません。
良い履歴
feat: ユーザー登録画面を追加
fix: パスワード検証のバグを修正
refactor: 認証ロジックをServiceへ分離
test: LoginServiceの単体テスト追加
docs: API仕様書を更新
履歴を見るだけでプロジェクトの変更内容が把握できます。
GitHubでの見え方
Pull Requestのコミット一覧も読みやすくなります。
feat: 商品一覧APIを追加
fix: 商品価格の計算ミスを修正
refactor: Repositoryの共通化
test: CartServiceのテスト追加
レビュー担当者も内容を素早く理解できます。
自動リリースとの相性も抜群
Conventional Commitsを採用すると、ツールがコミット内容を解析し、自動でリリースノートを生成できます。
例：
## ✨ Features
- 商品検索機能を追加
## 🐛 Bug Fixes
- ログインエラーを修正
- パスワード検証を改善
## ♻ Refactoring
- 認証処理を整理
手作業で変更履歴を書く必要がほとんどなくなります。
チーム開発でおすすめのルール
コミット前に以下の3点を確認しましょう。
✓ feat・fixなどのtypeを書く
✓ 何を変更したかを具体的に書く
✓ 1コミット1目的を意識する
例
git add .
git commit -m "feat: 商品検索APIを追加"
git commit -m "fix: パスワードのバリデーション漏れを修正"
git commit -m "refactor: 認証処理をAuthenticationServiceへ移動"
git commit -m "test: 商品検索APIのユニットテストを追加"
git commit -m "docs: 開発環境セットアップ手順を更新"
このようにConventional Commitsを習慣化することで、Git履歴が読みやすくなり、コードレビューや障害調査、リリース管理までスムーズになります。
まとめ
『修正』コミットを卒業して、チームが喜ぶ履歴を作りましょう！
#まだやってるんですか #コードの女神はみた #プログラミングスキル
動画で見る
YouTubeショート動画でも同じテーマを解説しています👇
チャンネル登録・高評価もよろしくお願いします 🔔
この記事は「コードの女神は見た！」チャンネルの連動記事です。