はじめに
チームで開していると、他人のコミットログを眺める機会が地味に多い。
そんなとき、更新 とか fix とか いろいろ修正 みたいなメッセージが並んでいると、正直なところ何が起きたのか全然わからない。
自分が過去に書いたものですら、3ヶ月後に見ると意味不明だったりする。
その「とりあえずコミットメッセージ問題」に一定の答えを出してくれるのが Conventional Commits というルールです。
今回はこれがどういうものか、ざっくり紹介します。
要するに、書き方を決めておくだけ
難しい仕組みではありません。コミットメッセージの先頭に「種類」を書く、というシンプルな約束事です。
基本の形はこれだけ。
type(scope): description
具体的にはこんな感じになります。
feat(auth): ログイン機能を追加
fix(api): ユーザー取得時のnullエラーを修正
docs: READMEのインストール手順を更新
scope（どこを触ったか）は省略してもOKで、feat: ログイン機能を追加 だけでも成立します。
最初は迷ったら付けない、くらいの気持ちで十分。
type は最初の数個だけ覚えればいい
公式が定めている type はいくつかありますが、実務で頻繁に使うのは限られています。
- feat … 新機能を追加したとき
- fix … バグを直したとき
- docs … ドキュメントだけの変更
- refactor … 機能は変えず、内部を整理したとき
- test … テストの追加・修正
- chore … ビルド設定やライブラリ更新など、雑多なもの
このあたりに style（フォーマット整形）や perf（パフォーマンス改善）が加わるくらい。
全部暗記しようとすると挫折するので、まずは feat と fix の使い分けから始めるのが現実的だと思います。
「破壊的変更」だけは特別扱い
互換性が壊れる変更、いわゆる Breaking Change については、ちゃんと目立たせる書き方が用意されています。
type のうしろに ! を付けるのが手軽です。
feat(api)!: レスポンス形式をJSONに統一
もっと丁寧に書くなら、本文に BREAKING CHANGE: から始まる説明を入れます。
feat(api): レスポンス形式を変更
BREAKING CHANGE: これまでXMLで返していたレスポンスをJSONに変更しました。
旧クライアントは動作しなくなります。
ここを雑にすると後で泣くので、破壊的変更だけはサボらないほうがいいです。
何が嬉しいのか
ルールを守って書くのは最初こそ面倒に感じます。
でも、続けていると地味に効いてくる場面がいくつかあります。
ひとつは、ログがそのまま履歴として読めること。feat を拾えば「この期間に何が増えたか」がひと目でわかるし、fix を追えば不具合の傾向も見えてきます。
もうひとつは、自動化と相性がいいこと。
Conventional Commits に沿っていれば、コミットログから CHANGELOG を自動生成したり、バージョン番号を自動で上げたりするツールがそのまま使えます。feat ならマイナーバージョン、fix ならパッチ、BREAKING CHANGE ならメジャー、といった具合に、セマンティックバージョニングともきれいに対応します。
つまり、人が読んでわかりやすいだけじゃなくて、機械にも処理させやすい。この両取りができるのが一番の強みだと思っています。
ルールを覚えるのが大変？ → skill にお任せ
「ルールを全員に覚えてもらうのが大変そう」という心配もありますが、その必要はありません。
下記の skill を使えば、ルールを知らなくても変更内容を確認し、コミットメッセージを自動生成できます。
導入は次のコマンドを実行するだけです。
bash npx skills add https://github.com/github/awesome-copilot --skill git-commit
まずは1週間だけ
コミットメッセージは、未来の自分とチームへのメモみたいなものです。
ほんの少し書き方を整えるだけで、後から見返したときの体験がだいぶ変わります。
だまされたと思って1週間ほど試してみてください。