Gitのコミットメッセージの接頭辞一覧！feat・fix・choreなどの意味と使い分けを解説！

Gitを使っていると、コミットメッセージの先頭にfeat:・fix:・chore:などの文字が付いていることがあります。

初めて見ると、「feat:は何の略？」「chore:はどんな変更に使うの？」と迷うこともあるでしょう。

これらは、変更の種類をわかりやすく伝えるための「接頭辞（プレフィックス）」です。

この記事では、Gitのコミットメッセージに使われる接頭辞について、以下の内容を具体例とあわせてわかりやすく解説します。

• 接頭辞の意味とConventional Commitsの基本
• よく使われる接頭辞の一覧
• 迷いやすい接頭辞の使い分け
• 変更内容が伝わるコミットメッセージの書き方

コミットメッセージの接頭辞とは？

コミットメッセージの接頭辞とは、変更の種類を示すために、メッセージの先頭に付ける短い言葉です。「プレフィックス（prefix）」とも呼ばれます。

コミットメッセージは、Gitに変更を記録するときに付ける説明文です。接頭辞を付けることで、機能追加なのか、バグ修正なのかを判断しやすくなります。

例えば、次のように書きます。

feat: 商品のお気に入り登録機能を追加
fix: ログインに失敗したときのエラー表示を修正
docs: READMEに開発環境の起動手順を追加

先頭のfeat:・fix:・docs:が接頭辞です。こうしたコミットメッセージの書き方の代表的な規約に「Conventional Commits」があります。

Conventional Commitsとは？

Conventional Commitsとは、コミットメッセージを一定の書式で記述するための規約です。

「変更の種類」「変更対象」「変更内容」を決まった形で書くことで、履歴を見た人が内容を把握しやすくなります。

人が読みやすくなるだけでなく、ツールが変更の種類を判別しやすくなることも特徴です。対応するツールと組み合わせることで、変更履歴の生成や、リリース時のバージョン番号の決定などを自動化できます。

Conventional Commitsの基本的な書式

Conventional Commitsの書式を以下に示します。

<type>[optional scope]: <description>

それぞれの項目の意味は、次のとおりです。

スコープを省略する場合は、接頭辞の後ろに変更内容を続けます。

feat: 商品のお気に入り登録機能を追加
docs: READMEに開発環境の起動手順を追加

変更対象も示したい場合は、次のようにスコープを付けます。

fix(auth): ログイン失敗時のエラー表示を修正
feat(search): 商品名の部分一致検索を追加

この例では、authが認証処理、searchが検索機能を示しています。スコープの名前は、プロジェクト内で意味が伝わるものを使用しましょう。

接頭辞の種類はプロジェクトに合わせる

Conventional Commitsでは、新機能の追加にはfeat、バグ修正にはfixを使うことが定められています。

docs・style・refactorなど、それ以外の接頭辞も使用できます。

ただし、すべての種類を採用する必要はありません。使用する接頭辞やスコープは、プロジェクトの規約に合わせて統一しましょう。

よく使われるコミットメッセージの接頭辞一覧

コミットメッセージで使われる代表的な接頭辞をまとめると、次のようになります。

ではこれから各接頭辞について詳しく説明します。

feat：新機能の追加

featは「feature」に由来し、新しい機能を追加するときに使います。

例えば、商品をお気に入りに登録できるようにする変更は、次のように書けます。

feat: 商品のお気に入り登録機能を追加

単にファイルを新しく作成しただけで、必ずfeatになるわけではありません。テストファイルの追加ならtest、説明資料の追加ならdocsなど、変更の目的で判断します。

fix：バグの修正

fixは、期待どおりに動かない処理や、誤った動作を修正するときに使います。

例えば、数量に0を入力できてしまう問題の修正は、次のように書けます。

fix: 注文数量に0を指定できる問題を修正

修正の規模や作業時間にかかわらず、バグを直す変更であればfixを使用できます。

docs：ドキュメントのみの変更

docsは「documents」や「documentation」に由来し、説明資料の追加・修正などに使います。

例えば、READMEの起動手順や誤字を修正する場合です。

docs: READMEの起動手順を修正
docs: インストール手順の誤字を修正

style：コードの書式の変更

styleは、空白や改行、インデントなど、コードの動作に影響しない書式の変更に使います。

例えば、インデントを統一する変更は、次のように書けます。

style: インデントをスペース2個に統一

セミコロンの追加・削除も、動作に影響しない場合は対象になります。構文エラーを直す変更であれば、fixとして扱う方が適切な場合があります。

refactor：コードの内部構造の整理

refactorは、外部から見た振る舞いを維持しながら、コードの内部構造を整理するときに使います。

例えば、複数の場所に書かれている同じ処理を、共通の関数にまとめる変更です。

refactor: 重複する送料計算を共通関数にまとめる

新しい機能を追加するのではなく、既存のコードを読みやすくしたり、修正しやすくしたりすることが目的です。

perf：パフォーマンスの改善

perfは「performance」に由来し、処理速度やメモリ使用量などを改善するときに使います。

例えば、ユーザー一覧を表示するときの不要なデータベース問い合わせを減らす変更です。

perf: ユーザー一覧のデータ取得を一括化して問い合わせ回数を削減

コードを整理した結果として処理が速くなることもありますが、性能改善が主な目的であれば、perfを使うと意図が伝わりやすくなります。

test：テストの追加・修正

testは、不足しているテストを追加したり、既存のテストを修正したりするときに使います。

例えば、パスワード未入力時のテストを追加する変更です。

test: パスワード未入力時のエラー表示を確認するテストを追加

バグ修正と、その修正を確認するテストを同じコミットに含める場合は、変更全体の目的に合わせてfixとすることもあります。

chore：補助的な開発・保守作業

choreは、英語で「雑用」や「日常的な作業」を意味する言葉です。コミットメッセージでは、機能追加やバグ修正などに分類しにくい、補助的な開発・保守作業に使います。

例えば、不要になった開発用設定を削除する変更です。

chore: 使用していない開発用設定を削除

ビルド処理、ドキュメント生成ツール、ライブラリの更新などをchoreに含めるプロジェクトもあります。

一方で、ビルドや依存関係の変更はbuild、自動テストの設定はciとして分けるプロジェクトもあります。choreの範囲はチームの規約を確認しましょう。

build：ビルドの仕組みや依存関係の変更

buildは、ソースコードから実行・配布用のファイルを作る「ビルド」の仕組みや、使用するライブラリなどの依存関係を変更するときに使います。

例えば、ビルドツールの設定や開発用ライブラリを更新する場合です。

build: ビルド時の出力先をdistに変更
build: 開発用ライブラリのバージョンを更新

こうした変更をchoreに含めるプロジェクトもあるため、チームの規約に合わせて使い分けましょう。

ci：自動ビルドや自動テストなどの設定変更

ciは「Continuous Integration（継続的インテグレーション）」の略です。コードを変更したときに、ビルドやテストを自動実行して問題を確認する仕組みの設定変更などに使います。

例えば、GitHub Actionsでテストを実行する条件を変更する場合です。

ci: Pull Requestの作成時にテストを実行する設定を追加
ci: 自動テストの対象にmainブランチを追加

テストコード自体の追加・修正にはtest、テストを自動実行する仕組みの設定変更にはciを使うと、違いがわかりやすくなります。

revert：過去の変更の取り消し

revertは、過去のコミットで加えた変更を取り消すときに使います。

例えば、追加した機能に問題が見つかり、その変更を取り消す場合です。

revert: 商品のお気に入り登録機能の追加を取り消す

詳しい理由や取り消し対象のコミットIDは、コミットメッセージの本文に記載すると、後から経緯を確認しやすくなります。

なお、revert:という接頭辞を書くだけで変更が取り消されるわけではありません。変更を取り消す操作には、git revertなどを使用します。

git revertで変更を取り消す場合は、取り消し対象を示すコミットメッセージが自動生成されます。

例えば、元のコミットサマリがfeat: 商品のお気に入り登録機能を追加であれば、通常は次のようになります。

Revert "feat: 商品のお気に入り登録機能を追加"

自動生成されるのは、大文字で始まるRevertを使った形式です。チームの規約でrevert:に統一している場合は、コミット時にメッセージを編集します。

style・refactor・perfの違い

style・refactor・perfは、いずれも既存のコードを変更するときに使われるため、迷いやすい接頭辞です。

主な違いを以下に示します。

例えば、同じ商品検索処理を変更する場合でも、次のように使い分けられます。

style: 商品検索処理のインデントを統一
refactor: 商品検索の条件生成処理を別の関数に分離
perf: 商品検索で取得するデータを必要な項目に限定

「どのファイルを変更したか」だけでなく、「何のために変更したか」を考えると判断しやすくなります。

プロジェクトによって使われる接頭辞

ここまでの接頭辞以外にも、チームや個人の規約として次のような分類が使われることがあります。

これらは、意味や使い分けが広く統一されているわけではありません。使用する場合は、チーム内でルールを決めておくことが大切です。ただし、Conventional Commitsに従う場合、新機能の追加にはfeat、バグ修正にはfixを使用します。

例えば、addを使わないプロジェクトでは、新機能の追加をfeat、テストの追加をtest、ドキュメントの追加をdocsと分類できます。

同様に、小さなミスであっても、バグを直すならfix、説明文の誤字ならdocs、インデントの修正ならstyleと判断できます。

レビュー後の変更も、「レビュー指摘に対応した」という理由だけで分類するのではなく、実際の変更内容に合わせてfixやrefactorなどを選ぶと、履歴から内容を把握しやすくなります。

本記事のまとめ

この記事では「Gitのコミットメッセージの接頭辞」について、以下の内容を説明しました。

• 接頭辞は、コミットに含まれる変更の種類を示すための言葉である
• Conventional Commitsは、コミットメッセージを一定の書式で記述するための規約である
• featは新機能の追加、fixはバグ修正、docsはドキュメントのみの変更に使う
• styleは書式の整理、refactorは内部構造の整理、perfは性能改善を目的とする

お読みいただきありがとうございました。