開発
Git Commit Conventions
Gitコミットメッセージの規約と一貫性のある履歴管理
Git Commit Conventions
このドキュメントは、プロジェクトにおけるGitコミットメッセージの規則を定義します。一貫性のあるコミット履歴を維持することで、変更履歴の追跡、自動化、コードレビューが容易になります。
1. コミットメッセージの基本構造
<type>(<scope>): <subject>
<body>
<footer>各要素の説明
- type: コミットの種類（必須）
- scope: 変更の影響範囲（オプション）
- subject: 変更の簡潔な説明（必須、50文字以内）
- body: 変更の詳細な説明（オプション、72文字で改行）
- footer: 破壊的変更やIssue参照（オプション）
2. Type（コミットの種類）
| Type | 説明 | 例 |
|---|---|---|
feat | 新機能の追加 | feat(explore): add tag filtering with search |
fix | バグ修正 | fix(chat): resolve message overflow issue |
docs | ドキュメントのみの変更 | docs(system): add UI/UX improvement scenario |
style | コードの意味に影響しない変更（空白、フォーマット、セミコロンなど） | style(button): adjust padding and margins |
refactor | バグ修正や機能追加を伴わないコードの改善 | refactor(api): simplify error handling logic |
perf | パフォーマンス改善 | perf(grid): optimize rendering with virtualization |
test | テストの追加や修正 | test(auth): add login flow tests |
build | ビルドシステムや外部依存関係の変更 | build(deps): upgrade next.js to 15.0.0 |
ci | CI設定ファイルやスクリプトの変更 | ci(vercel): update deployment config |
chore | その他の変更（ビルドプロセス、補助ツールなど） | chore(git): update .gitignore |
revert | 以前のコミットの取り消し | revert: feat(explore): add tag filtering |
3. Scope（影響範囲）
Scopeは変更が影響するモジュール、コンポーネント、機能領域を示します。プロジェクトの構造に応じて柔軟に設定してください。
推奨されるScope例
ページ/機能レベル:
explore- Exploreページbookshelf- Bookshelfページproject- プロジェクトエディタchat- AIチャット機能auth- 認証機能
コンポーネントレベル:
header- ヘッダーコンポーネントsearch- 検索機能tag-filter- タグフィルタリング
技術レベル:
db- データベースapi- APIui- UIコンポーネント全般state- 状態管理
ドキュメント:
system- システムドキュメントlog- 作業ログ
4. Subject（件名）
- 命令形を使用: "changed" ではなく "change"
- 最初の文字は小文字: "Add feature" ではなく "add feature"
- 末尾にピリオドを付けない
- 50文字以内に収める
- 何を変更したかを明確に: "fix bug" ではなく "fix message overflow in chat view"
良い例
feat(explore): add horizontal scrollable tag strip
fix(chat): resolve auto-scroll issue on new message
docs(system): add UI/UX improvement scenario to architecture
refactor(api): extract common error handling logic悪い例
Fixed stuff
Update files
WIP
asdf5. Body（本文）
- なぜ変更したかを説明する（何を変更したかはdiffで分かる）
- 変更前の問題点を記述する
- どのように解決したかを説明する
- 72文字で改行する
- 箇条書きを使用してもよい（
-または*を使用）
例
feat(explore): unify header design with bookshelf
The Explore and Bookshelf pages had inconsistent header designs,
leading to a disjointed user experience. This commit standardizes
the header layout across both pages:
- Adopt 3-column layout (icon+title, search, actions)
- Use consistent spacing and typography
- Implement responsive design for mobile and desktop
- Add Store icon for Explore page to match Library icon in Bookshelf
This improves visual consistency and user navigation between pages.6. Footer（フッター）
破壊的変更（Breaking Changes）
破壊的変更がある場合は、BREAKING CHANGE: で始まる段落をフッターに追加します。
feat(api): change authentication flow
BREAKING CHANGE: The authentication API now requires a new `deviceId`
parameter. All clients must be updated to include this parameter in
login requests.Issue参照
関連するIssueがある場合は、フッターで参照します。
Closes #123
Fixes #456, #789
Refs #2347. 実践例
例1: 新機能の追加
feat(explore): add tag filtering with search functionality
Users needed a way to filter projects by tags, especially when
there are many tags available. This commit implements:
- Horizontal scrollable tag strip for compact display
- Popover menu with Command component for tag search
- Visual feedback for active tags
- Gradient masks to indicate scrollability
The solution scales well even with 100+ tags.
Closes #234例2: バグ修正
fix(chat): resolve message overflow in narrow viewports
Messages were overflowing the container on mobile devices,
making them unreadable. Applied flex-wrap and adjusted
max-width constraints to ensure proper text wrapping.
Fixes #456例3: ドキュメント更新
docs(system): add UI/UX improvement scenario
Added new scenario F to document_architecture.md to provide
clear guidelines for UI/UX improvement tasks. This includes
checklists for component documentation, design tokens, and
accessibility considerations.例4: リファクタリング
refactor(api): extract common error handling logic
Extracted repetitive error handling code into a shared utility
function to improve maintainability and reduce code duplication
across API routes.8. AIアシスタント向けガイドライン
AIアシスタントがコミットメッセージを生成する際は、以下のプロセスに従ってください:
-
タスクの分析:
- 何を変更したか（WHAT）
- なぜ変更したか（WHY）
- どのように変更したか（HOW）
-
適切なTypeの選択:
- 変更の性質に最も適したtypeを選択
-
Scopeの特定:
- 変更が影響する主要な領域を特定
-
Subjectの作成:
- 50文字以内で変更を簡潔に説明
- 命令形、小文字で開始、ピリオドなし
-
Bodyの作成（必要に応じて）:
- 複雑な変更の場合は詳細な説明を追加
- 背景、問題点、解決方法を明確に
-
ユーザーへの提示:
- 生成したコミットメッセージをユーザーに提示
- 必要に応じて修正を受け付ける
9. コミット粒度のガイドライン
適切なコミット粒度
- 1つの論理的な変更 = 1コミット
- 関連する複数のファイルの変更は1つのコミットにまとめてもよい
- 異なる目的の変更は別々のコミットに分ける
良い例
# コミット1: 機能実装
feat(explore): add tag filtering UI
# コミット2: ドキュメント更新
docs(system): document tag filtering component
# コミット3: テスト追加
test(explore): add tag filtering tests悪い例
# 1つのコミットに複数の無関係な変更
feat: add tag filtering, fix chat bug, update docs, refactor API10. 参考資料
このコミット規則は以下の標準に基づいています:
最終更新: 2025-11-24
バージョン: 1.0.0