commits

Conventional Commits

変更履歴の自動生成とセマンティックバージョニングを可能にする、構造化されたコミットメッセージの仕様です。

クイックリファレンス

フォーマット

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

一般的なタイプ

タイプ	用途	SemVer
feat	新機能	MINOR
fix	バグ修正	PATCH
docs	ドキュメントのみ	-
style	フォーマット変更、コード変更なし	-
refactor	機能追加・修正を伴わないコード変更	-
perf	パフォーマンスの改善	-
test	テストの追加・修正	-
build	ビルドシステム、依存関係	-
ci	CI 設定	-
chore	メンテナンスタスク	-
revert	以前のコミットの取り消し	-

破壊的変更

feat!: send email when product shipped

feat(api)!: change response format

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

例

シンプルなコミット

feat: add user authentication
fix: resolve memory leak in cache
docs: update API documentation
style: format code with prettier
refactor: extract validation logic
perf: optimize database queries
test: add unit tests for auth module
build: upgrade webpack to v5
ci: add GitHub Actions workflow
chore: update dependencies

スコープ付き

feat(auth): add OAuth2 support
fix(parser): handle empty arrays
docs(readme): add installation guide
refactor(api): simplify error handling

本文付き

fix: prevent request racing

Introduce a request id and reference to latest request.
Dismiss incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue
but are obsolete now.

フッター付き

fix: correct minor typos in code

Reviewed-by: John Doe
Refs: #123

フッターでの破壊的変更

feat: allow config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used
for extending other config files.

! とフッターを使った破壊的変更

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

コミットの取り消し

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

仕様ルール

MUST

1. コミットの先頭にはタイプ（feat、fix など）を付ける必要があります
2. タイプの後にはコロンとスペースを付ける必要があります
3. 説明はコロンとスペースの直後に記述する必要があります
4. 新機能には feat を使用する必要があります
5. バグ修正には fix を使用する必要があります
6. 破壊的変更は : の前に ! を付けるか、フッターに BREAKING CHANGE: を記述して示す必要があります
7. BREAKING CHANGE は大文字で記述する必要があります
8. フッターのトークンでは、スペースの代わりに - を使用する必要があります（例：Reviewed-by）

MAY

1. タイプの後にスコープを指定できます：feat(parser):
2. 説明の後に本文を記述できます（間に空行を入れます）
3. 本文の後にフッターを記述できます（間に空行を入れます）
4. feat と fix 以外のタイプも使用できます
5. BREAKING CHANGE: のフッターと ! を併用できます

大文字・小文字の区別

• タイプ：大文字・小文字を区別しません（統一性のため小文字を推奨）
• BREAKING CHANGE：大文字で記述する必要があります
• BREAKING-CHANGE：BREAKING CHANGE と同義です

SemVer との対応

コミットタイプ	SemVer の更新	バージョン変更
fix:	PATCH	1.0.0 → 1.0.1
feat:	MINOR	1.0.0 → 1.1.0
BREAKING CHANGE または !	MAJOR	1.0.0 → 2.0.0

破壊的変更はタイプより優先されます。fix!: は MAJOR 更新になります。

変更履歴との連携

Conventional Commits は 変更履歴 の項目に直接対応します：

コミットタイプ	変更履歴のセクション
feat	追加
fix	修正
perf	変更
refactor	変更
docs	（通常は省略、または変更）
BREAKING CHANGE	変更／削除セクションで強調
revert	削除または修正
セキュリティ修正	セキュリティ

変更履歴の自動生成

conventional-changelog、semantic-release、release-please などのツールでは、次のことができます：

• コミットメッセージを解析する
• CHANGELOG.md の項目を生成する
• 次のバージョン番号を決定する
• リリースを自動で作成する

CHANGELOG.md のフォーマットについては、変更履歴のスキル を参照してください。

よくあるパターン

機能開発

git commit -m "feat(users): add profile page"
git commit -m "feat(users): add avatar upload"
git commit -m "test(users): add profile page tests"
git commit -m "docs(users): document profile API"

参照情報付きのバグ修正

git commit -m "fix(auth): resolve session timeout (#142)"

破壊的変更のフロー

# Deprecate first
git commit -m "feat(api): add v2 endpoint

DEPRECATED: /api/v1/users will be removed in next major version"

# Later, remove
git commit -m "feat(api)!: remove v1 endpoints

BREAKING CHANGE: /api/v1/* endpoints have been removed.
Use /api/v2/* instead."

FAQ

コミットが複数のタイプに当てはまる場合は？

可能であれば、複数のコミットに分けてください。履歴がより整理されます。

間違ったタイプを使った場合は？

マージ前：git rebase -i を使って履歴を編集します。
リリース後：重大な問題ではありません。コミットは自動化ツールで見落とされます。

すべてのコントリビューターがこれを使う必要がありますか？

いいえ。スカッシュマージを使えば、メンテナーがマージ用の適切なメッセージを記述できます。

リバートの扱い方

revert: <original commit subject>

Refs: <commit SHA>

Git の設定

コミットテンプレート

テンプレートを使用するよう Git を設定します。

git config commit.template .gitmessage

テンプレートファイルについては、assets/commit-msg.template を参照してください。

コミット前の検証

Git フックまたは CI で assets/validate-commit-msg.sh を使用します。

ツール

ツール	目的
commitlint	コミットメッセージのリント
commitizen	対話型のコミット支援ツール
conventional-changelog	変更履歴の生成
semantic-release	リリースの自動化
release-please	GitHub リリースの自動化

重大な禁止事項

• 曖昧なメッセージ（「fix stuff」「update」「wip」など）を使用しないでください
• 1 つのコミットに関連のない変更を混在させないでください
• 破壊的変更の表示を省略しないでください
• チームの合意なしに標準外のタイプを使用しないでください
• 説明と本文の間の空行を忘れないでください

コミットメッセージ作成時のエージェントのワークフロー

必須：ブランチ名、コミットメッセージ、または PR の説明を提案する前に、エージェントは必ず次の作業を行う必要があります。

1. git status または git diff --name-only を使って、変更されたファイルをすべて確認する
2. git diff（ステージ済みと未ステージの両方）を使って、実際の変更内容を確認する
3. すべての変更を分析する — 会話で言及されたファイルだけに限定しない
4. 変更されたファイルを一部だけでなくすべて含め、変更内容全体に基づいて提案する

ワークフローの手順

# Step 1: Get list of all changed files
git status --short

# Step 2: Review actual changes (for unstaged)
git diff

# Step 3: Review staged changes
git diff --staged

# Step 4: Use the complete changeset to propose:
#   - Branch name
#   - Commit message
#   - PR description

出力形式

ユーザーからコミットメッセージを求められた場合は、次を提示します。

1. ブランチ名の候補（標準的なプレフィックスを使った 3 つの案）
2. コミットメッセージの候補（短文・中程度・詳細）
3. PR の説明（変更履歴全体をそのまま重複させず、要約する）

すべての提案は、推測ではなく実際の git diff の出力に基づいている必要があります。

リンク

• 公式仕様：https://www.conventionalcommits.org/en/v1.0.0/
• セマンティックバージョニング：https://semver.org/spec/v2.0.0.html
• 関連項目：changelog skill — CHANGELOG.md の形式

テンプレート

• commit-msg.template — Git コミットメッセージのテンプレート
• validate-commit-msg.sh — 検証スクリプト