皆さん、こんにちは！私は開発エンジニア歴6年、T&Cテクノロジーズに
入社して3年目のR★です！
今日は業務中に知った「Conventional Commits」について紹介します！
このテーマを選んだ理由は、業務内でコミットメッセージの標準化に
取り組むことになった中で、統一されたフォーマットに従ったコミット
メッセージによってコード変更の目的や種類が分かりやすくなったことに
感動したからです。
新しい機能を開発する時に「Conventional Commits」を使うと、進捗が追いやすく、
チーム全体で協力しやすい開発プロセスが築けます。ぜひ参考にしてみてください！
■Conventional Commits」って何？
コミットメッセージを一定化するための開発プロジェクト全体で一貫性を保つように
標準化された手法です。具体的には、コミットメッセージに「fix:」、「chore:」などといった
特定のプレフィックスを使用し簡潔な文言を記載していくものです。
■基本的な形式は
●type(scope): description
– type：どのようなコミット種別かを表すプレフィックス（例：feat、fix、test）
– scope：コンポーネント名やファイル名など変更による影響範囲指定のオプション
– description： コミットで行った変更の内容を表す文言
●例
– feat: ユーザー登録機能の追加
– fix: ○○のバリデーション桁数が仕様通り(10桁)でなかったため修正
– chore: 不要コメントの削除
また、互換性を保たない大きな変更が有った場合にはBREAKING CHANGEという
特別なフラグを使用します。本フラグの付いたコミットは、メジャーバージョンのアップデートを
意味しています。BREAKING CHANGEは、type末尾に!マークを追加して記載、またはコミット
メッセージの最後に記載(例2)します。
●例1） feat!: ユーザー登録機能の仕様変更
●例2） feat(UserModel): ユーザー登録機能のモデル刷新
BREAKING CHANGE: 登録APIの登録形式を変更
■導入のメリットは3つ！
①自動化しやすい
Conventional Commitsに準拠したコミットメッセージを書くことで、そのコミットメッセージから
CHANGELOG（変更履歴）を自動生成できます。
「feat:」や「fix:」といったプレフィックスを使用することで、機能追加やバグ修正の情報が明確に！
●例：CHANGELOG自動生成
– https://github.com/conventional-changelog/conventional-changelog
また、ビルド～リリースを自動化することでリリースノートに記載するバージョン情報には
どのような機能・バグ修正が入っているかわかりやすくなります。
●例：ビルドやリリース自動化
– https://github.com/semantic-release/commit-analyzer
②コードレビューがしやすくなる
人間にとってわかりやすいコミットメッセージがあると、レビュアーはそのコミットの
目的と影響を一目で理解しやすい！
ただ「修正」というコミットメッセージのみだと「何を修正したのか？」わかり辛い！
Conventional Commitsに準拠し、「fix: ○○のバリデーション桁数が仕様通り(10桁)で
なかった為、修正」といった内容であればレビュアーもわかりやすいです！
③コミットの粒度が安定する
Conventional Commitsにおいて、異なる種別の変更は可能な限りコミットを分けた粒度で
扱います。コミット履歴で変更単位が一定のコミット粒度になることで、後から変更を
追いたい場合にも追いやすくなります。
●例：Function1、Function2のバグを修正、Function3を追加、ドキュメント修正した場合
– fix(Function1): 関数Aの○○バグを修正
– fix(Function2): 関数Bの○○バグを修正
– feat(Function3): ○○を行う関数Dを追加
●docs: Function1、Function2、Function3のドキュメント更新
様々な箇所の変更を丸ごと1つのコミットで行ってしまうと後から見た時に非常に
わかり辛いづらいです。
Conventional Commitsを取り入れることで、それぞれのコミットの目的が何かが明瞭になり、
デプロイ後に作成するリリースノートで見たときの変更履歴もわかりやすくなります。
参考として、主なプレフィックス・オプションをご紹介します！
■主なプレフィックス
●feat:新機能やクラス、関数などを追加した時
– 例:feat: ユーザー登録機能の追加
●fix:バグを修正した時
– 例: fix:バグ○○を修正
●chore:コードへの影響が無い変更の時（ビルド・リリースなど）
– 例: chore:ビルドスクリプトを更新
●docs:ドキュメントを変更した時
– 例: docs:READMEを更新
●style:コードの意味的に影響がない変更の時（空白、フォーマット、セミコロンの欠落など）
– 例: style: インデントを修正
●refactor:バグ修正、機能追加を行わないコード変更の時
– 例: refactor: 煩雑な計算処理を見やすく分割
●perf:パフォーマンス改善するコード変更の時
– 例: perf: MYSQLのチューニング
●test:テストの追加や修正の時
– 例: test: 単体テストを修正
■オプション
!:互換性を伴わない変更の時
– 例: feat!: API仕様を変更
-(scope):変更による影響範囲（モジュール、ファイル、関数など）を明確にする時
– 例:fix(user): ユーザー登録の名称バリデーションのバグ修正
最後まで読んで頂いてありがとうございます！
少しでもお役に立てると嬉しいです。