日本語プロジェクト向け
はじめに
本ガイドラインは、プロジェクトにおける Git コミットメッセージの記述ルールを統一し、チーム開発におけるコード変更履歴の可読性・保守性・運用効率を高めることを目的としています。
バージョン管理においてコミットメッセージは、開発者間の意思疎通、レビューの円滑化、CI/CD連携、そして将来的な変更追跡において重要な役割を果たします。明確かつ一貫性のあるメッセージスタイルを採用することで、以下のような効果が期待されます：
- チームメンバー間の認識統一とレビュー効率の向上
- 過去の変更履歴の検索性・再利用性の向上
- 自動リリースノート生成やデプロイパイプラインとの整合性確保
本ガイドラインは、日々の開発で実用的かつ柔軟に運用できるよう設計されています。プロジェクトのフェーズや開発規模に応じて拡張・調整することも可能です。
チーム全体での共通理解と運用の徹底を通じて、よりスムーズな開発体験を実現しましょう。
🧭 基本方針
- 目的の明確化：変更内容と意図が伝わるように書く
- 履歴の読みやすさ重視：あとから見返しても理解できる内容にする
- 自動化と整合性：CI/CDやリリースノート生成と連携可能な構造にする
📝 コミットメッセージ構成
形式（1行目）
<prefix>: <変更内容の要約>（全角日本語または英語）
✅ 日本語プロジェクトでは全角日本語を推奨。ただし
<prefix>は英語表記で統一。
🏷 使用するプレフィックス一覧（アルファベット順）
| Prefix | 用途 | 詳細説明 |
|---|---|---|
Add: |
新機能の追加 | 新たな機能、画面、モジュール、APIなどを追加した際に使用。アプリの振る舞いに直接影響する新規開発を表す。 |
Chore: |
雑務・構成調整 | 機能に直接関係しないビルド設定、CI/CDの調整、依存ライブラリのアップデートなどに使用。日常的なメンテナンス作業。 |
Config: |
設定ファイル関連 | .env, .gitignore, .editorconfig, .eslintrc など、設定ファイルの追加・修正に使用。 |
Deploy: |
デプロイ対応 | 本番またはステージング環境へのデプロイ対応・準備作業。インフラ構成ファイルや設定変更、バージョンスイッチなどを含む。 |
Docs: |
ドキュメント更新 | README、仕様書、設計資料、コメント等のドキュメント類を追加・修正した場合に使用。 |
Fix: |
バグ修正 | ロジックエラーや表示崩れ、クラッシュなどの不具合を修正する場合に使用。 |
Hotfix: |
緊急修正 | 本番環境での不具合や障害などに対する迅速な修正に使用。影響範囲が大きいためレビュー・確認は慎重に行う。 |
PoC: |
検証・試作 | 技術検証や概念実証（Proof of Concept）のための仮実装に使用。品質担保や完成度は問わない。 |
Refactor: |
リファクタリング | 振る舞いは変えず、コードの内部構造や設計を改善した場合に使用。命名整理、関数分割、抽象化など。 |
Release: |
バージョンの節目・公開準備 | マイルストーン達成やバージョンアップに使用。v1.0 などのタグ🏷と併用し、リリースノートやCI/CDと連携しやすくする。 |
Remove: |
削除 | 使用されなくなった機能、コード、ファイル、依存ライブラリなどを削除した場合に使用。 |
Style: |
コードスタイル変更 | インデント、空白、改行、コメント、フォーマッタの適用など機能に影響を与えない整形に使用。 |
Test: |
テスト関連 | 単体テスト、結合テスト、モック、テストデータの追加・修正に使用。 |
Update: |
改良・仕様調整 | 機能の改善や微調整、UI・UXの向上、文言の修正、既存処理の仕様変更などに使用。 |
WIP: |
作業途中のスナップショット | 実装中の作業を一時的に保存する目的のコミット。未完成のため、最終的には squash や rebase でまとめてから main にマージすること。 |
💡 コミットメッセージ例
Add: ログイン画面のUIを新規作成
Fix: サインアップ時に発生する500エラーを修正
Update: 入力チェックを非同期化してUX向上
Remove: 未使用のバリデーション関数を削除
Refactor: 認証周りのロジックをクラスベースに再構築
Docs: READMEに環境構築手順を追加
Test: ユーザ登録処理のテストケースを追加
Style: HTMLテンプレートのインデントと空白を整理
WIP: プロフィール編集機能の途中実装（保存未対応）
PoC: GraphQL導入の技術検証コード
Hotfix: 本番環境で発生した画像アップロードバグの緊急修正
Release: v0.2 マイルストーン達成（フォーム送信と確認画面を実装）
Deploy: 本番環境へ v0.2 を反映
Chore: ESLintルールをプロジェクト標準に統一
Config: `.env.example` に新しい環境変数を追加
📌 用途別クイックリファレンス
| 作業内容 | 推奨Prefix |
|---|---|
| マイルストーン完了／タグ付与 | Release: |
| 本番環境へ反映 | Deploy: |
| CI設定・依存更新 | Chore: |
| .envなどの構成ファイル修正 | Config: |
🚧 WIP・試行系コミットの使い分け
| Prefix | 用途 | 詳細説明 |
|---|---|---|
WIP: |
開発途中、未完成のコードのチェックポイント | 実装中の機能や構成を一時的に保存する目的で使用。動作確認の途中、または設計未確定の状態。後で squash して整理することを前提とする。main や本番にはマージ禁止。 |
Try: |
新技術・新方式の試行 | 新しい手法や実装パターンの試行的コミット。成功前提ではないため、不要になれば破棄してもよい。選定・比較の材料としても使用される。 |
PoC: |
概念実証・技術検証 | 技術的可能性を検証するための仮実装。設計・品質よりも「動くこと」「確認できること」が優先される。機能や構成は後で作り直す前提。 |
Temp: |
一時的な回避・仮実装 | 将来的に置き換えることが前提の仮実装や応急処置（例：バグ回避のための暫定コードなど）。そのまま運用し続けることは想定しない。 |
Checkpoint: |
作業中の進捗スナップショット | 作業の途中段階を記録する目的で使用。大きな実装作業の中間点などに適しており、ローカル作業のバックアップとしても有効。内容の完成度は問わないが、mainにはそのまま入れないことが望ましい。 |
⚠
WIP:やPoC:の状態でmainブランチへマージしないこと。Pull Request 作成時には、最終的にRebaseやSquashして履歴を整理してください。
✅ 利用シーン別ガイド
- 「一部分はひとまず完成した」 →
WIP: - 「この方法が使えるか試してみた」→
Try: - 「技術的に成立するか検証した」→
PoC: - 「一時的にバグを応急回避した」→
Temp: - 「とりあえず保存しておいた」→
Checkpoint:
📄 詳細メッセージ（2行目以降）
2行目を空け、3行目以降に詳細な説明を記述：
Add: メール通知機能を実装
・ユーザー登録時に確認メールを送信
・SMTP設定を環境ファイルに追加
・エラーハンドリングは今後対応予定
WIP: 新デザインテーマ適用作業（ヘッダー周辺のみ対応）
・グローバルナビとロゴ周辺のCSSを更新
・レスポンシブ対応は未実装
・旧スタイルが一部残っており、整理が必要
・途中状態でもレイアウトが崩れないよう調整済み
🔀 ブランチ命名規則（参考）
| ブランチ種別 | 命名例 |
|---|---|
| 機能追加 | feature/login-form |
| バグ修正 | bugfix/signup-error |
| リファクタ | refactor/user-service |
| ドキュメント | docs/setup-guide |
| 緊急対応 | hotfix/production-crash |
📦 運用ベストプラクティス
- ローカル作業中は細かくコミット、PR前に整理（
squash推奨） mainへの直接コミットは禁止（Pull Request経由）- 定期的に
git log --onelineで履歴を点検 - 共有ブランチやPRは分かりやすい命名を心がける
🧪 補足：.gitmessage テンプレート
<prefix>: 変更内容の要約
・なぜこの変更が必要か
・具体的な対応内容
・今後の課題やTODO（あれば）
Git設定例：
git config --global commit.template ~/.gitmessage
📄 ライセンス
本ガイドラインは CC0 1.0 Universal (CC0 1.0) パブリックドメイン のもとに提供されています。
著作権を完全に放棄しており、出典の記載や許諾なしに、商用・非商用を問わず自由に利用・複製・改変・再配布することができます。
※ チーム全員でシェアしやすいよう必要最小限度でまとめました。本ガイドラインは今後も適時改善することがあります。