Conventional Commitsの書き方｜運用ルール例つき

開発ツール

Conventional Commitsは、コミットメッセージの書式を統一する規約です。自動化されたCHANGELOG生成・セマンティックバージョニングと相性が良く、近年広く採用されています。本記事では、Conventional Commitsの書き方と運用ルールを解説します。

基本フォーマット

<type>(<scope>): <subject>

[body]

[footer]

代表的なtype

  • feat：新機能追加
  • fix：バグ修正
  • docs：ドキュメント
  • style：見た目・フォーマット（処理に影響しない）
  • refactor：リファクタ（機能変更なし）
  • test：テスト追加・修正
  • chore：ビルド・依存などの雑務
  • perf：パフォーマンス改善
  • ci：CI設定変更
  • build：ビルド関連
  • revert：リバート

書き方の例

feat(auth): add OAuth login

Google・GitHubでのOAuthログインを追加。
セッションはJWTで管理。

Closes #123
fix(api): correct user search query
docs(readme): add setup steps
refactor(db): split UserRepository into queries/commands

Breaking Change

feat(api)!: change user response shape

BREAKING CHANGE: /users APIのレスポンスから`age`を削除し、`birthday`に変更。

typeの後に「!」を付けるか、footerに BREAKING CHANGE: を書くと、メジャーバージョンが上がる扱いになります。

自動化との連携

  • semantic-release：commitからversion bumpとCHANGELOGを自動生成
  • commitlint：コミットメッセージの書式チェック
  • husky：pre-commit hookでcommitlintを実行
  • release-please：Googleの自動リリースPRツール

運用ルール例

  • subjectは50文字以内、命令形（add / fix / update）
  • 本文は72文字で改行、変更理由を書く
  • scopeはモジュール・パッケージ名（auth、api、ui等）
  • 1コミット1目的を徹底
  • Squash MergeでPR単位を1コミットにまとめても良い

まとめ

Conventional Commitsは「人にもツールにも読める履歴」を作る仕組みです。type(scope): subjectの書式を全員が守ることで、CHANGELOGや自動リリースが回るようになり、長期運用が楽になります。