はじめに
こんにちは、nobushiueshiです。
みなさんはGitのコミットメッセージ、どのように書いていますか？「とりあえず fix で…」と書いてしまうこともありますよね。
最近は絵文字 ✨ を使うgitmojiを使って分かりやすくする工夫も人気ですが、今日はそれよりも一歩進んだ「Conventional Commits」というルールを紹介します。これを使うと、開発がぐっと楽になります。
Conventional Commitsって何？
まず、「Conventional Commits」についてご存じない方のために、その概要を簡単に説明します。
Conventional Commitsは、コミットメッセージの記述に関する規約です。
簡単に言えば、「統一されたコミットメッセージの構造を提供するルール」みたいなものです。
詳細な仕様については、公式サイト（日本語版も提供されています）をご参照いただくのが最も正確です。ぜひ一度、目を通されることをお勧めします。
基本的なメッセージ構造は以下の通りです。
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]例を挙げると、以下のようになります。
feat(api): 新しいユーザー認証エンドポイントを実装
ユーザー登録およびログイン機能を提供します。
JWT（JSON Web Token）を利用したセッショントークンを発行する仕様です。
Reviewed-by: Z
Refs: #123ただ、ほとんどがオプショナルなので私はほとんどが以下のように必須のもののみ記述しています。
feat: 新しいユーザー認証エンドポイントを実装また、この構造における type は、コミットの種類を示します。代表的な type には以下のようなものがあります。
| type | 種類 |
|---|---|
| feat | 新機能の開発・実装 |
| fix | バグの修正 |
| docs | ドキュメントのみの変更 |
| style | スタイル(UI)に関する変更 |
| refactor | バグ修正や機能追加を伴わないコードのリファクタリング |
| perf | パフォーマンス改善を目的としたコード変更 |
| test | 不足しているテストの追加や、既存テストの修正 |
| chore | ビルドプロセスや補助ツール、ライブラリ（ドキュメント生成など）の変更 |
なぜConventional Commitsがいいの？
では、このルールを守るとどんな良いことがあるのでしょうか？
変更履歴がとにかく分かりやすい
feat なのか fix なのか、api なのか ui なのか。コミットメッセージを一目見るだけで、「どんな変更」が「どこに」行われたのかがすぐに分かります。後から変更履歴を追いかけるのが、とても楽になります。
CHANGELOG（変更履歴）を自動で作れる
これが最大のメリットかもしれません。feat や fix のコミットを元に、ツールが自動でCHANGELOGを生成してくれます。リリース前の面倒な手作業がなくなり、記載漏れの心配もありません。
チーム開発の認識がそろう
「この変更は新機能？それともリファクタリング？」といった認識のズレがなくなります。チーム全員が同じルールで書くことで、コードレビューもスムーズに進みます。
試してみる価値は大いにアリ！
Conventional Commitsは、単にコミットメッセージを綺麗にするだけでなく、CHANGELOGの自動生成やチーム開発の円滑化といった、具体的なメリットに繋がります。
もちろんgitmojiの楽しさも素敵ですが、もし日々の開発で「変更履歴を追うのが大変…」「リリース作業が面倒…」と感じているなら、きっとこのルールが助けになるはずです。
最初は少し覚えることがありますが、慣れるとむしろ迷わず書けるようになります。ぜひ、次のプロジェクトから試してみてはいかがでしょうか？
参考
コメント