なんでConventional Commitsってそんなに大事なの？Git履歴は“構造”なのよねって話🌈
この記事では、Conventional Commits（構造化されたコミットメッセージ）の「形式がめっちゃ大事な理由」について語ります。
「読みやすくなるから〜」じゃなくて、履歴を情報資産として活かすための超大事な構文ルールだってこと、しっかり理解しよ〜！
ちなこれ前回の記事
💥直したって何をよ？地獄コミットメッセ問題、ギャルがConventional Commitsで救う🌈
🧩 Gitログって、ただの履歴じゃなくて「状態の変化の記録」なのよ〜！
開発してると、機能足したり、バグ直したり、コードきれいにしたりするよね？
それ全部、システムの“状態”が変わってるってこと。
でさ、その変化を記録してくれてるのがGitログなの。
つまり、Gitの履歴って「状態遷移のログ」なのよね！
※ Gitの履歴は、技術的に「コミット（＝スナップショットの連続）」だが、実務的には「状態遷移の記録」として設計上も扱われる。
🧠 フォーマットに“意味”があると、いろいろラクになる！
✅ 1. コミットを機械的に抽出できる
git log --grep "^feat" --oneline
git log --grep "^refactor" --pretty=format:"%h %s"
※ --grep オプションは、正規表現マッチによりプレフィックス（例：feat:）での抽出が可能。
形式が統一されてれば、「どれが新機能？」とか「これは整理？」とか一発で絞れる！
自由に書いてたら、全部目で読んで探す羽目になるし、それ地獄。
✅ 2. CI/CDの自動化にも組み込みやすい
構文が決まってるから、ツールが理解しやすいんだよね。
# CHANGELOG を自動生成
npx conventional-changelog -p angular -i CHANGELOG.md -s
# semantic-release でバージョン更新も自動
npx semantic-release
-
feat:→ MINORアップ -
fix:→ PATCHアップ
※ BREAKING CHANGE: の注釈を含めると semantic-release は MAJOR バージョンを上げるよう動作する。詳細は semantic-release公式ドキュメント 参照。
こういうの、人間が判断しなくて済むって、ほんとありがたい。
✅ 3. MRの説明文にそのまま使える（実際にやってる）
筆者はマジでこれやってる。
git log origin/main..HEAD --pretty=format:"- %s"
これだけで、「今回なにしたのか」一覧がそのままMRの概要になる。
説明文を一から書く必要なし。便利すぎ。
※ origin/main..HEAD は「まだmainにマージされていないコミット」を表し、プレーンなログ出力がそのまま要約文になる。
✅ 4. 履歴がチームの共通言語になる
-
refactor:が多ければ → コード整理のタイミング -
chore:が増えてたら → ツールやCI整備してる時期
みたいに、履歴からチームの“動き”が読めるのがマジ便利。
「今なにしてる時期なのか」が見えるって、地味にありがたい。
❌ 自由形式ログって、マジであとから地獄
修正
ちょっと直した
対応済み
やった
修正2
このへん、ほんとにやめよ？
- 自動分類できない
- 検索もできない
- なにがどう変わったのかも不明
＝過去が闇。未来も闇。Gitログが使えなくなるだけじゃなくて、チーム全体が詰む。
🌟 Conventional Commitsは「履歴を使えるインフラ」にするための構文
Gitログって、ただの記録じゃなくて、
**「設計の記録」「チームの会話」「仕様の変更履歴」**なんだよね。
ちゃんと書けば、設計レビューにも使えるし、障害調査にも役立つし、ナレッジにもなる。
Conventional Commitsはそのための構文ルール＝ログの言語化ってこと！
※ Conventional Commits 1.0.0 仕様 により、構文形式が明示され、ツール間での共通処理が可能となる。
🛠 補助ツール（ちゃんと書けるようにするやつ）
- commitlint：ルール違反を教えてくれる
- husky：Gitフックでルール強制できる
- semantic-release：CHANGELOG・バージョン自動
- VSCode拡張：入力補助が超便利
📣 最後に：形式は“自由になるためのルール”なのよ！
「型があると縛られそう…」って思う人もいるかもだけど、
実際はその逆で、ルールがあるから他に頭使えるの。
Conventional Commitsは、**履歴を読みやすくするためだけじゃなくて、使いやすく・再利用できるようにするための“未来への投資”**なんだよね。
履歴は未来の自分とチームへのラブレター。
書き方ひとつで、あとあとめっちゃ助かるから、今日から整えてこ〜！
💜 次回予告：Spring Bootの設定ファイルって、結局どう使えばいいの？
次回はこれ👇
『Spring Bootで共通情報を外部ファイルに持たせる意味とおすすめの書き方』
画面タイトルとかURLパスとか、ついコードにベタ書きしちゃってない？
でもそれ、あとで地味にめんどくなるから、最初から整理しとくのが吉なんだよね。
この記事では「構造的に履歴を扱う」って話をしたけど、設定情報も構造的に扱うのが鉄則！
次回は、Spring Bootアプリケーションで画面名やパスなどの共通値を、どう整理して再利用性を高めるかを解説予定。
「なんでわざわざ yml に出すの？」って疑問もスッキリ解決できるから、ぜひチェックしてみて〜。