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

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

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

ちなこれ前回の記事
[💥直したって何をよ？地獄コミットメッセ問題、ギャルがConventional Commitsで救う🌈](https://qiita.com/doruboxshiki/items/af3914e65f1f9f514583)

---

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

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

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

```mermaid
graph LR
A[初期状態] --> B[機能追加] --> C[バグ修正] --> D[設計改善]
```

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

---

## 🧠 フォーマットに“意味”があると、いろいろラクになる！

### ✅ 1. コミットを機械的に抽出できる

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

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

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

---

### ✅ 2. CI/CDの自動化にも組み込みやすい

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

```bash
# 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公式ドキュメント](https://semantic-release.gitbook.io/) 参照。

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

---

### ✅ 3. MRの説明文にそのまま使える（実際にやってる）

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

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

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

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

---

### ✅ 4. 履歴がチームの共通言語になる

- `refactor:` が多ければ → コード整理のタイミング
- `chore:` が増えてたら → ツールやCI整備してる時期

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

---

## ❌ 自由形式ログって、マジであとから地獄

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

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

- 自動分類できない
- 検索もできない
- なにがどう変わったのかも不明

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

---

## 🌟 Conventional Commitsは「履歴を使えるインフラ」にするための構文

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

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

※ [Conventional Commits 1.0.0 仕様](https://www.conventionalcommits.org/en/v1.0.0/) により、構文形式が明示され、ツール間での共通処理が可能となる。

---

## 🛠 補助ツール（ちゃんと書けるようにするやつ）

- [commitlint](https://commitlint.js.org/)：ルール違反を教えてくれる
- [husky](https://typicode.github.io/husky)：Gitフックでルール強制できる
- [semantic-release](https://semantic-release.gitbook.io/)：CHANGELOG・バージョン自動
- [VSCode拡張](https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits)：入力補助が超便利

---

## 📣 最後に：形式は“自由になるためのルール”なのよ！

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

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

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

---

## 💜 次回予告：Spring Bootの設定ファイルって、結局どう使えばいいの？

次回はこれ👇

### 『[🌟Spring Boot設定のベストプラクティス｜画面名やパスを外部ファイルで管理する理由と方法💡](https://qiita.com/doruboxshiki/items/c5cc5e6be2720fb7ed33)』

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

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

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