前に書く
よく他人のコミット履歴に feat、fix、chore などが含まれているのを見かけますが、私はコミット時に特に区別せずにそのままメッセージを書いていました。今日はそのあたりを整理してみます。例として element-plus を見てみましょう。
実はこれはコードコミットの規約です。もちろんテクニックを見せるためではなく、主な目的はコミット履歴の可読性と自動処理の能力を高めることです。
もちろん、チームに要件がなければこのように書かなくても構いません。
git コミット規約
コミットメッセージ = subject + ：+ スペース + message 本体
例： feat: ユーザー登録機能を追加
よく使われる subject の種類とその意味は次の通りです。
- feat: 新機能（feature）
新しい機能をコミットするために使用します。
例：feat: ユーザー登録機能を追加
- fix: バグ修正
バグ修正をコミットするために使用します。
例：fix: ログインページがクラッシュする問題を修正
- docs: ドキュメント変更
ドキュメントのみに関連する修正をコミットするために使用します。
例：docs: READMEファイルを更新
- style: コードスタイルの変更（コードロジックに影響しない）
フォーマット、句読点、空白など、コードの実行に影響しない変更をコミットするために使用します。
例：style: 余分な空行を削除
- refactor: リファクタリング（新機能追加でもバグ修正でもないコード変更）
コードのリファクタリングをコミットするために使用します。
例：refactor: ユーザー認証ロジックをリファクタリング
- perf: パフォーマンス最適化
パフォーマンスを向上させるコード変更をコミットするために使用します。
例：perf: 画像読み込み速度を最適化
- test: テストの追加または修正
テスト関連の内容をコミットするために使用します。
例：test: ユーザーモジュールの単体テストを追加
- chore: 雑作業（ビルドプロセスや補助ツールの変更）
ビルドプロセスや補助ツールなどに関連する変更をコミットするために使用します。
例：chore: 依存ライブラリを更新
- build: ビルドシステムまたは外部依存関係の変更
ビルドシステムに影響を与える変更をコミットするために使用します。
例：build: webpack をバージョン5にアップグレード
- ci: 継続的インテグレーション設定の変更
CI 設定ファイルやスクリプトの変更をコミットするために使用します。
例：ci: GitHub Actions の設定ファイルを修正
- revert: ロールバック
以前のコミットをロールバックするために使用します。
例：revert: feat: ユーザー登録機能を追加 をロールバック
まとめ
規約に従ったコミットメッセージを使用することで、プロジェクトをよりモジュール化し、保守や理解が容易になり、さらに自動化ツール（リリースツールや Changelog 生成ツールなど）がコミット履歴を解析・処理しやすくなります。
規約に沿ったコミットメッセージを作成することで、チームや協力者がプロジェクトの変更履歴やバージョン管理をよりよく理解でき、コードの保守効率と品質が向上します。