Zenn
😺

【Git】コミットメッセージのprefix

に公開
1件
Git
tech

コミットメッセージにプレフィックスを付けることで、変更の目的や内容を簡潔に伝えることができます。
今日はそのプレフィックスと使用例について紹介していきます。

プレフィックスの標準仕様

コミットメッセージのプレフィックスにはConventional Commitsという標準的な仕様があります。
多くのOSSプロジェクトや開発チームで採用されており、自動化ツールとの連携も容易になります。
この辺りも大変興味深いですが、今回は基本的なプレフィックスの紹介にとどめるので、興味のある方はぜひ、以下の公式サイトで詳しい内容をご覧ください。

参考: Conventional Commits - コミットメッセージの標準仕様（公式・日本語）

基本的なプレフィックス

では本題に移りましょう。
こちらはConventional Commitsで定義されている主要なプレフィックスです。
現場でもよく見かけるものばかりですね。

プレフィックス 用途 使用例
feat 新機能の追加 feat: ユーザー登録機能の実装
fix バグ修正 fix: ログイン時のセッション切れエラーを修正
docs ドキュメントの更新・追加 docs: READMEにインストール手順を追加
style コードの意味に影響しない変更 style: インデントをタブからスペースに変更
refactor バグ修正や機能追加を行わないコード変更 refactor: ユーザー認証処理のリファクタリング
perf パフォーマンス改善 perf: データベースクエリの最適化
test テストの追加・修正 test: ユーザー登録のユニットテストを追加
build ビルドシステムや外部依存関係の変更 build: webpackの設定を更新
ci CI設定ファイルやスクリプトの変更 ci: GitHub Actionsのワークフローを追加
chore その他の変更（ソースやテストファイルを変更しない） chore: npmパッケージのアップデート
revert 以前のコミットを元に戻す revert: "ログイン機能の変更"を元に戻す

併せて使われるパターン

スコープ付きコミット

特定の機能やファイルに関する変更の場合

feat(auth): ログイン機能を追加
fix(api): ユーザー取得APIのエラーハンドリングを修正
docs(readme): インストール手順を更新

Issue番号付きコミット

GitHubのIssueと連携する場合

fix: #456 ボタンのスタイルが崩れる問題を修正
feat: #789 ダークモード機能を実装

これでコミット、プッシュすると、それぞれ#456や#789の該当のIssueのページにこのコミットが連携されて表示されるのでわかりやすくて良いですね。

使用例

実際のコミットメッセージでは、以下のように使用します。

新機能追加の例

feat: ログイン機能の実装

- ユーザー名とパスワードによる認証を追加
- セッション管理の実装
- ログインフォームのUIを作成

バグ修正の例

fix: #123 パスワードリセット機能のバグ修正

- リセットトークンの有効期限チェックを追加
- エラーメッセージの改善

ドキュメント更新の例

docs: API仕様書を更新

- 新しいエンドポイントの説明を追加
- レスポンス形式の例を修正

良い例

  • 簡潔で明確: feat: ユーザー検索機能を追加
  • Issue番号付き: fix: #123 ログインボタンが動作しない問題を修正
  • スコープ付き: refactor(auth): パスワード検証ロジックを整理

推奨しない例

  • 曖昧: fix: バグ修正
  • 詳細すぎる: feat: ユーザーがログインフォームに入力した情報を検証して...
  • 複数の変更: feat: ログイン機能追加とバグ修正とドキュメント更新

チェックリスト

  • 適切なプレフィックスを選択している
  • 変更内容が一目で分かる
  • 50文字以内など、冗長にならず簡潔にまとめている
  • 必要に応じてIssue番号を含めている
  • チーム内で一貫性がある

プレフィックスを適切に使用することでコードの変更履歴が整理され、変更の目的内容も伝わりやすくなります。
プロジェクトやチームの方針によって書き方は変わるので、他の方がどう書いているか、どういうやり方をしているのか見て聞いて吸収していきたいですね。

参考リンク

今回の記事に関連する公式ドキュメントや参考情報です。