Top

コミット規約

本ドキュメントでは、Gitのコミットメッセージおよびコミットの粒度に関するガイドラインをまとめます。履歴の可読性を高め、変更内容の追跡を容易にすることを目的としています。

コミットの粒度

コミットは「意味のある最小単位」で分割することを推奨します。

対応内容ごとにコミットを分ける:
- 1つのコミットに複数の異なる修正（例：機能追加とリファクタリング）を混ぜないでください。
- 修正が混ざると、特定の変更だけを元に戻す（revert）ことが困難になります。
動作する状態でコミットする:
- コンパイルエラーが発生する状態や、テストが失敗する状態でのコミットは避けてください（WIPコミットを共有ブランチにプッシュする場合を除きます）。

コミットメッセージの構成

変更内容が即座に理解できるように記載します。

基本フォーマット

<type>: <summary>

<body> (optional)

type（変更の種類）

GitHubのIssueやPull Requestと共通のプレフィックスを使用します。

feat:: 新機能
fix:: バグ修正
docs:: ドキュメントのみの修正
style:: コードの意味に影響を与えない変更（ホワイトスペース、フォーマット、セミコロンの欠落など）
refactor:: バグ修正でも機能追加でもないコードの変更
perf:: パフォーマンスを向上させる変更
test:: 不足しているテストの追加や既存のテストの修正
chore:: ビルドプロセスやドキュメント生成などの補助ツール、ライブラリの変更

summary（要約）

簡潔かつ具体的: 1行目は50文字程度を目安に、変更内容を端的に記述します。
チケットIDの記載: 関連するチケットがある場合は含めます（例: feat: [ISSUE-123] ログイン機能の実装）。

body（本文）

なぜ（Why）を記述する: 変更の理由や、どのように修正したかの補足を、空行を1行挟んで記載します。
箇条書きの活用: 複数の小さな変更が含まれる場合は、箇条書きで分かりやすく記載します。

よいコミットメッセージの例

feat: [ISSUE-45] ユーザー登録時のバリデーション追加

- メールアドレスの重複チェック処理を追加
- パスワードの最小文字数を8文字に変更
- エラーメッセージを日本語化

関連ドキュメント: