Zenn
🔰

伝わる！Gitコミットメッセージの書き方

に公開
Git
GitHub
初心者
GitLab
入門
tech

日々の開発で欠かせない Git。その中でも、コミットメッセージは変更履歴を管理し、チーム開発を円滑に進める上で非常に重要な役割を果たします。本記事では、可読性が高く、意図が伝わりやすいコミットメッセージの書き方について解説します。

なぜ良いコミットメッセージが重要なのか？

良いコミットメッセージは、以下のようなメリットをもたらします。

  • 変更履歴の可読性向上: 何が、なぜ変更されたのかが一目でわかります。
  • 問題の追跡: バグが発生した際に、どのコミットが原因かを特定しやすくなります。
  • コードレビューの効率化: レビュー担当者は、コミットメッセージを読むことで変更の意図を理解しやすくなります。
  • ドキュメントとしての活用: コミットログ自体が、プロジェクトの変遷を記録したドキュメントとして活用できます。

コミットメッセージの基本構造

コミットメッセージの構造は以下の通りです。

<type>(<scope>): #<Issue Number> <subject>

<body>

<footer>

それぞれの要素について詳しく見ていきましょう。

<type>: コミットの種類を示す Prefix

コミットの種類を示す短いキーワードです。プロジェクトの変更内容を分類し、コミットの意図を明確にするために使用します。一般的に使用される Prefix とその使用場面は以下の通りです。

Prefix 説明 使用場面
feat 新機能の追加 新しい機能を追加したコミット
fix バグの修正 バグを修正したコミット
docs ドキュメントの変更 ドキュメント（例: README, API ドキュメントなど）を追加、修正、削除したコミット
style コードのスタイルに関する変更 (フォーマット、セミコロンなど) コードの意味に影響を与えないスタイルの修正（例: インデントの修正、不要な空白の削除、コードフォーマットの適用など）
refactor コードのリファクタリング (機能変更なし) コードの内部構造を変更したが、外部から見た動作は変わらないコミット（例: 変数名の変更、関数の分割・統合、ロジックの整理など）
test テストコードの追加、修正 新しいテストコードの追加や既存のテストコードの修正を行ったコミット
chore ビルドプロセス、補助ツール、依存関係などの管理に関する変更 開発環境やビルドシステムに関する変更（例: 依存ライブラリの更新、タスクランナーの設定変更、gitignore の修正など）
perf パフォーマンス改善に関する変更 コードのパフォーマンスを向上させるための変更を行ったコミット
build ビルドシステムや外部依存関係に関する変更 ビルドプロセス自体や、それに必要な外部ライブラリなどの依存関係を変更したコミット
ci CI (継続的インテグレーション) パイプラインの設定やスクリプトに関する変更 GitHub Actions、CircleCI などの CI/CD に関する設定ファイルやスクリプトを変更したコミット
revert 直前のコミットを取り消す変更 誤った変更を取り消すために git revert コマンドを実行した際に生成されるコミット

(<scope>): スコープ (任意)

変更が影響する範囲を示す任意の要素です。例えば、特定のコンポーネント、モジュール、ファイルなどを記述します。複数のスコープにまたがる場合は省略しても構いません。

#<Issue Number>: Issue トラッカーの ID

変更内容に関連する Issue トラッカーの ID です。

<subject>: 短い概要

変更内容を簡潔にまとめた一行の概要です。多くても 30 文字程度に収めることが推奨されます。命令形で記述し、「ユーザー登録機能を追加」のように具体的に記述します。

<body>: 詳細な説明 (任意)

変更の理由、背景、具体的な内容などを詳細に記述します。必要に応じて複数行にわたっても構いません。なぜその変更を行ったのか、どのような影響があるのかなどを記述すると、より理解が深まります。

<footer>: フッター (任意)

関連する Issue の ID や、破壊的な変更（Breaking Changes）に関する情報を記述します。

  • Issue Tracking: #123, Closes #456 のように、関連する Issue トラッカーの ID を記述します。
  • Breaking Changes: BREAKING CHANGE: APIのレスポンス形式が変更されました。 のように、後方互換性のない変更について明示的に記述します。

コミットメッセージを書く際のポイント

  • 一貫性: プロジェクト全体で一貫した Prefix やフォーマットを使用するように心がけましょう。
  • 具体性: 何を変更したのかを具体的に記述しましょう。「修正しました」だけでなく、「〇〇に関する問題を修正しました」のように記述します。
  • 簡潔性: 短く分かりやすい言葉で記述しましょう。
  • 命令形: <subject> は命令形で記述しましょう。
  • 最初の行を重要視: 最初の行（<type>(<scope>): #<Issue Number>　<subject>) は特に重要です。変更の概要が一目でわかるように記述しましょう。

コミットメッセージの例

feat(user): #10 ユーザー登録機能を追加

ユーザーがメールアドレスとパスワードでアカウントを作成できるようにしました。
入力validationやエラーハンドリングも実装済みです。

Closes #10

この例では、以下の情報が明確に伝わります。

  • 種類: feat (新機能の追加)
  • スコープ: user (ユーザー関連の機能)
  • Issue ID: #10
  • 概要: ユーザー登録機能を追加した
  • 詳細: 実装内容（メールアドレスとパスワードでの登録、validation、エラーハンドリング）
  • 関連 Issue: Issue #10 をクローズする

まとめ

良いコミットメッセージを書くことは、自分自身だけでなく、チーム全体の生産性向上に繋がります。本記事で紹介した内容を参考に、より分かりやすく、価値のあるコミットメッセージを作成する習慣を身につけていきましょう。

参考

https://zenn.dev/itosho/articles/git-commit-message-2023
https://qiita.com/itosho/items/9565c6ad2ffc24c09364
https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

GitHubで編集を提案

Discussion