チームで開発を進める上で、コミットメッセージの品質はプロジェクトの長期的な保守性に大きく影響します。
適切なコミットメッセージは「なぜこの変更を行ったか」を後から確認できる重要な記録であり、チーム全体で統一されたルールに従うことで変更履歴が圧倒的に読みやすくなります。
本記事ではコミットメッセージのルール・フォーマット・ベストプラクティスについて詳しく解説していきます。
コミットメッセージのルール：基本的な結論
それではまず、良いコミットメッセージの基本的な原則について解説していきます。
良いコミットメッセージの基本原則として、Tim Popeが提唱した「7つのルール」が広く参照されています。
コミットメッセージの7つのルール
| ルール | 内容 |
|---|---|
| 1. 件名と本文を空行で区切る | 件名と本文は空行1行で分離する |
| 2. 件名は72文字以内 | GitHubなどで省略されないよう短くまとめる |
| 3. 件名の末尾にピリオドを付けない | タイトルにピリオドは不要 |
| 4. 件名は命令形で書く | 「〜を修正」ではなく「〜を修正する」命令の形 |
| 5. 本文を72文字で折り返す | ターミナルでの可読性を保つ |
| 6. 本文でWhatではなくWhyを説明する | 何をしたかより、なぜしたかを記述する |
| 7. 件名は大文字で始める | 英語の場合は先頭を大文字にする |
コミットメッセージの基本構造
コミットメッセージは「件名（Subject）」「空行」「本文（Body）」「空行」「フッター（Footer）」という構造を持ちます。
コミットメッセージの基本フォーマット
件名：変更内容の簡潔な要約（72文字以内）
（空行）
本文：変更の理由・背景・アプローチの説明
（空行）
フッター：参照するIssue番号・BreakingChangeなど
件名だけのシンプルなコミットでも問題ありませんが、複雑な変更や設計上の判断を含む場合は本文で「なぜ」を説明することが後々の保守性向上に大きく貢献します。
WHATよりWHYを書く重要性
コミットメッセージで最もよくある誤りが「何をしたか（WHAT）」だけを書いてしまうことです。
「バグを修正した」「ロジックを変更した」というWHATはコードを見ればわかりますが、「なぜそのバグが発生していたか」「なぜこの設計を選んだか」というWHYはコードから読み取ることが難しいでしょう。
WHYを記述することで、数ヶ月後に同じコードを見た際に変更の意図が一目でわかり、誤った変更による退行（リグレッション）を防ぐことができます。
Conventional Commitsによる統一フォーマット
続いては、現在多くのプロジェクトで採用されている「Conventional Commits」という統一フォーマットを確認していきます。
Conventional Commitsの基本形式
Conventional Commitsは「type(scope): description」という形式でコミットメッセージの件名を統一する規約です。
Conventional Commitsのフォーマット例
feat(auth): ユーザーログイン機能を追加
fix(api): nullポインタ例外を修正
docs(readme): インストール手順を更新
refactor(user): ユーザーサービスのメソッドを整理
test(cart): カート追加機能の単体テストを追加
コミットタイプの種類
Conventional Commitsで使用される主なタイプには以下のものがあります。
| タイプ | 意味 | 使用場面 |
|---|---|---|
| feat | 新機能 | 新しい機能の追加 |
| fix | バグ修正 | バグの修正 |
| docs | ドキュメント | ドキュメントの変更 |
| style | スタイル | コードスタイルの修正（動作変更なし） |
| refactor | リファクタリング | 機能変更なしのコード改善 |
| test | テスト | テストコードの追加・修正 |
| chore | 雑務 | ビルド設定・依存関係の更新など |
Conventional Commitsを採用することでCHANGELOGの自動生成・セマンティックバージョニングの自動化が可能になり、リリース管理の効率が大幅に向上します。
チームでの運用ルールとツールの活用
続いては、チームでコミットメッセージのルールを運用する際の実践方法を確認していきます。
Commitlintによる自動チェック
コミットメッセージのフォーマットを自動チェックするツールとしてCommitlintが広く活用されています。
GitのCommit-msgフックと組み合わせることで、ルールに違反したコミットメッセージを自動的に拒否する仕組みを構築できます。
自動チェックを導入することでルールの周知と遵守を仕組みで担保でき、人的レビューコストを削減できます。
日本語と英語の使い分け
グローバルなチームでは英語、日本語のみのチームでは日本語を使用するのが一般的です。
いずれの言語を選ぶ場合も、チーム全体で統一することが最も重要であり、メンバーによって言語がバラバラになることは避けるべきでしょう。
日本語の場合は「〜を追加」「〜を修正」という動詞で終わる体言形が読みやすいコミットメッセージの書き方として広く使われています。
まとめ
本記事では、コミットメッセージのルール・基本構造・Conventional Commitsフォーマット・チームでの運用方法について解説しました。
良いコミットメッセージは72文字以内の件名・WHYを説明する本文・統一されたフォーマットという要素で構成されており、Conventional Commitsの採用と自動チェックツールの導入によってチーム全体の品質が向上します。
コミットメッセージはプロジェクトの変更履歴という貴重な資産であり、丁寧に記述する習慣がチームの長期的な開発効率を大きく左右します。
本日から意識的にコミットメッセージの品質向上に取り組んでいきましょう。
