Git
コミットメッセージとタグ
Conventional Commitsに準拠したコミットメッセージの書き方とタグ運用
コミットメッセージ規約
なぜConventional Commitsを使うのか
- 変更内容の明確化: コミットの目的が一目で分かる
- リリースノート自動生成: 変更履歴を自動的に作成できる
- セマンティックバージョニング: バージョン番号の自動決定が可能
- チーム内の統一: 誰が書いても同じ形式になる
開発初期やリリース前は、スピード重視でコミットメッセージが雑でも構いません。
※プッシュやマージのし忘れには注意してください。
※プッシュやマージのし忘れには注意してください。
フォーマット
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
基本構造
- type: コミットの種類（必須）
- scope: 変更の範囲（省略可）
- description: 変更内容の簡潔な説明（必須）
- body: 詳細な説明（省略可）
- footer: 破壊的変更やIssue参照（省略可）
scope（スコープ）、body（本文）、footer は省略可能です。
短い修正や説明不要な場合は 1 行のみでも問題ありません。
type の種類
主要なtype
| type | 説明 | 例 |
|---|---|---|
feat | 新機能の追加 | feat: ユーザー登録機能の追加 |
fix | バグ修正 | fix: ログインフォームのバリデーションエラー修正 |
docs | ドキュメントのみの変更 | docs: READMEのセットアップ手順を更新 |
style | コードの意味に影響しないフォーマット変更 | style: インデントを修正 |
refactor | リファクタリング（機能変更なし） | refactor: APIクライアントを関数化 |
perf | パフォーマンス改善 | perf: 画像の遅延読み込みを実装 |
test | テストの追加・修正 | test: ユーザー認証のテストを追加 |
chore | ビルドプロセスやツールの変更 | chore: 依存関係を更新 |
その他のtype（任意）
| type | 説明 | 例 |
|---|---|---|
build | ビルドシステムの変更 | build: webpackの設定を更新 |
ci | CI設定の変更 | ci: GitHub Actionsのワークフローを追加 |
revert | 以前のコミットの取り消し | revert: "feat: ユーザー登録機能の追加" |
scope の使い方
scopeは変更の範囲を示します（省略可）。
feat(auth): ログイン機能の追加
fix(api): ユーザー取得のエラーハンドリング修正
docs(readme): セットアップ手順を追記
style(button): ボタンのスタイルを統一
scopeの例
- コンポーネント名:
button,header,modal - 機能領域:
auth,payment,search - ファイル名:
index,config,utils
scopeは短く、意味が明確であることが重要です。
プロジェクト内で統一したscopeを使うと、検索や履歴の整理が容易になります。
description の書き方
descriptionは変更内容を簡潔に説明します。
feat: ユーザー認証機能を追加
fix: ログインフォームのバリデーションエラーを修正
docs: API仕様書を更新
refactor: データ取得ロジックを共通化
update
fix bug
変更
WIP
descriptionのルール
- 動詞で始める: 「追加」「修正」「更新」など
- 現在形を使う: 「追加した」ではなく「追加」
- 簡潔に: 50文字以内を目安に
- 具体的に: 何を変更したか明確に
body の使い方
詳細な説明が必要な場合は、bodyを使用します。
feat: ユーザー認証機能を追加
JWT トークンを使用した認証システムを実装しました。
ログイン、ログアウト、トークンリフレッシュに対応しています。
セキュリティ向上のため、HTTPOnlyクッキーにトークンを保存します。
bodyは省略可能です。
コミットの内容が複雑で、descriptionだけでは説明しきれない場合に使用してください。
footer の使い方
Breaking Change（破壊的変更）
APIの変更など、後方互換性のない変更がある場合は明記します。
feat: API レスポンス形式を変更
BREAKING CHANGE: APIレスポンスの形式が変更されました。
以前は { data: {...} } でしたが、現在は { result: {...} } になります。
Issue参照
関連するIssueがある場合は、footerで参照します。
fix: ログインエラーを修正
Closes #123
feat: 検索機能を追加
Resolves #45
Refs #46, #47
実例
シンプルな例
feat: ダークモード対応
fix: 画像が表示されない問題を修正
docs: コントリビューションガイドを追加
style: コードフォーマットを統一
refactor: useAuthフックを作成
test: ログイン機能のテストを追加
chore: ESLintの設定を更新
scope付き
feat(auth): パスワードリセット機能を追加
fix(api): ユーザー一覧取得のページネーションを修正
docs(deploy): デプロイ手順を更新
refactor(hooks): カスタムフックを共通化
body付き
feat: メール通知機能を実装
SendGridを使用したメール送信システムを追加しました。
以下のイベント発生時に通知を送信します：
- ユーザー登録完了
- パスワードリセット
- 重要なアカウント変更
環境変数 SENDGRID_API_KEY の設定が必要です。
Breaking Change付き
refactor: 環境変数名を変更
BREAKING CHANGE: 環境変数の命名規則を統一しました。
以下の環境変数名が変更されています：
- API_KEY → VITE_API_KEY
- DB_URL → DATABASE_URL
- SECRET → JWT_SECRET
.env ファイルを更新してください。
タグ運用
必要に応じて、Gitタグを使用してバージョンを管理できます。
タグ運用は必須ではありません。
タグの命名規則
セマンティックバージョニング（SemVer）に準拠します。
v<major>.<minor>.<patch>
例:
v1.0.0
v1.2.3
v2.0.0-beta.1
- major: 破壊的変更がある場合に上げる
- minor: 後方互換性のある機能追加
- patch: 後方互換性のあるバグ修正
プロジェクトによっては、日付ベースのタグ（例:
release20250114）を使用することもあります。
導入する場合は、チーム内で統一されたルールに従ってください。タグの作成
git tag v1.0.0
git push origin v1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0
注釈付きタグの推奨注釈付きタグには、作成者、日時、メッセージが記録されます。
リリース管理には注釈付きタグを使用することを推奨します。
タグの一覧表示
# すべてのタグを表示
git tag
# パターンに一致するタグを表示
git tag -l "v1.*"
# タグの詳細を表示
git show v1.0.0
タグの削除
git tag -d v1.0.0
git push origin --delete v1.0.0
タグの削除は慎重に一度公開したタグは、他の人が使用している可能性があります。
誤って作成した場合を除き、既存のタグは削除しないことを推奨します。
リリースノートの自動生成
Conventional Commitsに準拠することで、必要に応じてリリースノートを自動生成できます。
リリースノートは必須ではありません。
ツールの例
- standard-version: バージョン管理とCHANGELOG生成
- semantic-release: 完全自動リリース
- release-please: GitHub Actions での自動リリース
# package.jsonに追加
{
"scripts": {
"release": "standard-version"
}
}
# 実行
npm run release
自動的に以下が行われます：
- バージョン番号の決定
- CHANGELOG.md の更新
- Gitタグの作成
- package.json のバージョン更新
GitHub Releasesとの連携タグを作成すると、GitHubのReleasesページでリリースノートを公開できます。