なんでConventional Commitsってそんなに大事なの？Git履歴は“構造”なのよねって話🌈

この記事では、Conventional Commits（構造化されたコミットメッセージ）の「形式がめっちゃ大事な理由」について語ります。
「読みやすくなるから〜」じゃなくて、履歴を情報資産として活かすための超大事な構文ルールだってこと、しっかり理解しよ〜！

🧩 Gitログって、ただの履歴じゃなくて「状態の変化の記録」なのよ〜！

開発してると、機能足したり、バグ直したり、コードきれいにしたりするよね？
それ全部、システムの“状態”が変わってるってこと。

でさ、その変化を記録してくれてるのがGitログなの。
つまり、Gitの履歴って「状態遷移のログ」なのよね！

※ Gitの履歴は、技術的に「コミット（＝スナップショットの連続）」だが、実務的には「状態遷移の記録」として設計上も扱われる。

git log --grep "^feat" --oneline
git log --grep "^refactor" --pretty=format:"%h %s"

※ --grep オプションは、正規表現マッチによりプレフィックス（例：feat:）での抽出が可能。

形式が統一されてれば、「どれが新機能？」とか「これは整理？」とか一発で絞れる！
自由に書いてたら、全部目で読んで探す羽目になるし、それ地獄。

構文が決まってるから、ツールが理解しやすいんだよね。

# CHANGELOG を自動生成
npx conventional-changelog -p angular -i CHANGELOG.md -s

# semantic-release でバージョン更新も自動
npx semantic-release

※ BREAKING CHANGE: の注釈を含めると semantic-release は MAJOR バージョンを上げるよう動作する。詳細は semantic-release公式ドキュメント参照。

こういうの、人間が判断しなくて済むって、ほんとありがたい。

筆者はマジでこれやってる。

git log origin/main..HEAD --pretty=format:"- %s"

これだけで、「今回なにしたのか」一覧がそのままMRの概要になる。
説明文を一から書く必要なし。便利すぎ。

※ origin/main..HEAD は「まだmainにマージされていないコミット」を表し、プレーンなログ出力がそのまま要約文になる。

みたいに、履歴からチームの“動き”が読めるのがマジ便利。
「今なにしてる時期なのか」が見えるって、地味にありがたい。

修正
ちょっと直した
対応済み
やった
修正2

このへん、ほんとにやめよ？

＝過去が闇。未来も闇。Gitログが使えなくなるだけじゃなくて、チーム全体が詰む。

Gitログって、ただの記録じゃなくて、
**「設計の記録」「チームの会話」「仕様の変更履歴」**なんだよね。

ちゃんと書けば、設計レビューにも使えるし、障害調査にも役立つし、ナレッジにもなる。
Conventional Commitsはそのための構文ルール＝ログの言語化ってこと！

※ Conventional Commits 1.0.0 仕様により、構文形式が明示され、ツール間での共通処理が可能となる。

「型があると縛られそう…」って思う人もいるかもだけど、
実際はその逆で、ルールがあるから他に頭使えるの。

Conventional Commitsは、**履歴を読みやすくするためだけじゃなくて、使いやすく・再利用できるようにするための“未来への投資”**なんだよね。

履歴は未来の自分とチームへのラブレター。
書き方ひとつで、あとあとめっちゃ助かるから、今日から整えてこ〜！

次回はこれ👇

画面タイトルとかURLパスとか、ついコードにベタ書きしちゃってない？
でもそれ、あとで地味にめんどくなるから、最初から整理しとくのが吉なんだよね。

この記事では「構造的に履歴を扱う」って話をしたけど、設定情報も構造的に扱うのが鉄則！
次回は、Spring Bootアプリケーションで画面名やパスなどの共通値を、どう整理して再利用性を高めるかを解説予定。

「なんでわざわざ yml に出すの？」って疑問もスッキリ解決できるから、ぜひチェックしてみて〜。