Gitでの開発中、こんな経験ありませんか?
「このコミットって何をしたんだっけ?」
「チームの人のコミット、ルールがバラバラで読みにくい…」
そんなときに役立つのが、コミットメッセージのPrefix(プレフィックス)を使うルールです。
この記事では、よく使われるPrefixの意味や使い分け、チームでの活用方法をまとめてご紹介します!
こんな人におすすめ!
・Gitに慣れてきたけど、コミットの書き方に迷う人
・チーム開発のルールを整えたい人
・ログが読みにくくて困っている人
1. そもそもPrefixってなに?なんで必要なの?
Prefixとは、コミットメッセージの先頭につける「変更の種類」を示す単語のことです。
これをつけておくと、Gitログを見たときに、どんな変更かが一目でわかります。
例えばこんな感じです。
fix: ログイン時のバグを修正
docs: READMEを更新
チームでの開発やコードレビュー、リリース作業がスムーズになります!
2. よく使われるPrefix一覧と意味

Prefix | 意味・用途 | 使用例 |
---|---|---|
feat | 新しい機能の追加 | feat: ユーザーのプロフィール編集機能を追加 |
fix | バグ修正 | fix: ログイン時にセッションが切れる問題を修正 |
docs | ドキュメントの修正・更新 | docs: READMEに開発環境のセットアップ手順を追加 |
style | 見た目の変更(動作に影響なし) | style: コードのインデントをスペースに統一 |
refactor | 機能変更なしのコード改善(リファクタリング) | refactor: 複雑な条件分岐を関数に分割 |
perf | パフォーマンス改善 | perf: クエリの実行速度を最適化 |
test | テストコードの追加・変更 | test: 商品購入処理のユニットテストを追加 |
chore | 雑務(設定ファイルなど) | chore: eslintの設定を追加 |
build | ビルド関連 | build: production用にwebpack設定を変更 |
ci | CIツール関連の設定 | ci: GitHub Actionsでテストを実行するよう追加 |
revert | 以前の変更を取り消し | revert: feat: 画像アップロード機能を追加 を取り消し |
add | ファイルやライブラリの追加 | add: axiosライブラリを追加 |
update | 既存の機能やライブラリを更新 | update: bootstrapのバージョンを5に更新 |
change | 機能や仕様の変更 | change: パスワードの最小文字数を8文字に変更 |
hotfix | 緊急バグ修正 | hotfix: 本番環境で発生していたクラッシュを修正 |
clean | 不要なコードの削除など | clean: 未使用のimport文を削除 |
disable | 一時的な無効化 | disable: お知らせバナーの表示を一時的に停止 |
remove | ファイルや機能の削除 | remove: 旧ログイン画面のコードを削除 |
delete | ファイルの削除 | delete: debug用ログ出力処理を削除 |
rename | ファイルや関数名の変更 | rename: UserList.js を MemberList.js に変更 |
move | ファイルの移動 | move: assetsディレクトリに画像ファイルを移動 |
upgrade | ライブラリ等のバージョンアップ | upgrade: Reactを18.0にアップグレード |
💡補足ポイント
- Prefixはコロン
:
のあとにスペースを入れるのが一般的(例:fix: 修正内容
) - プレフィックスだけで伝わらない場合は本文に詳細を書くとより親切
3. Prefixの使い分け、どうする?
例えば、「送信ボタンを追加して、それに関するテストも書いた」場合。
コミットを2回に分けるのがベストです。
feat: 送信ボタンを追加
test: 送信ボタンのテストを追加
後から見たときに、変更内容がはっきり分かれていると便利です。
4. チームでPrefixルールを統一しよう
チームで開発する場合、使うPrefixはあらかじめ決めておくのがオススメです。
例えばこんな感じ。
ルールは CONTRIBUTING.md
やREADME.md
に書いておくと、初参加の人にも優しいです。
5. Prefix入力をラクにする便利ツール
Prefixを簡単に入力できるツールもあります。
【Commitizen】
→ コマンドライン上で質問形式でコミットを作成できるツール
https://github.com/commitizen/cz-cli
【Conventional Commits】
→ Prefixのルールを定めた標準仕様
https://www.conventionalcommits.org/ja/v1.0.0/
6. まとめ
・Prefixをつけることで、Gitログがわかりやすくなる
・開発効率・レビュー効率もUP!
・チームではPrefixルールを統一しよう
・ツールを使えば運用も楽ちん
おまけ:Prefix用テンプレート(コピペOK)
feat: 新しい機能の追加(例: feat: 通知機能を追加)
fix: バグ修正(例: fix: パスワードが保存されない不具合を修正)
docs: ドキュメントの追加・変更(例: docs: API仕様をREADMEに追記)
style: コードの見た目を変更(例: style: セミコロンの統一)
refactor: 機能に影響を与えないコードの改善(例: refactor: if文を関数に切り出し)
perf: パフォーマンス改善(例: perf: 無駄なループ処理を削除)
test: テストコードの追加・修正(例: test: ログイン機能のテストを追加)
chore: 雑務(ビルド設定、依存関係など)(例: chore: npmパッケージを最新に更新)
build: ビルド関連の変更(例: build: webpackのproduction設定を変更)
ci: CI関連の設定(例: ci: GitHub Actionsの設定ファイルを追加)
revert: 以前のコミットを取り消し(例: revert: feat: 検索機能を追加)
add: 新しいファイルやライブラリの追加(例: add: Vue.jsをプロジェクトに導入)
update: 機能の小規模な更新や依存の更新(例: update: eslintのバージョンを更新)
change: 機能や仕様の変更(例: change: ユーザー登録にメール認証を追加)
hotfix: 緊急バグ修正(例: hotfix: サイトがクラッシュする問題を修正)
clean: 不要なコードやコメントの削除(例: clean: 使われていない関数を削除)
disable: 機能の一時的な無効化(例: disable: テストのため通知機能を停止)
remove: ファイルやコードの削除(例: remove: 不要になったバナー機能を削除)
delete: ファイル削除と同義(例: delete: 旧版のレイアウトファイルを削除)
rename: ファイルや関数名の変更(例: rename: home.htmlをindex.htmlに変更)
move: ファイルやフォルダの移動(例: move: scriptsフォルダにjsファイルを移動)
upgrade: ライブラリなどのバージョンアップ(例: upgrade: Vue3にアップグレード)
コメント