はじめに
Gitを使い始めた人、Gitを独学で頑張っている人、チーム開発でGitに慣れていない人が抱える悩みで、
Gitでコミットする時、こんな風に思っていませんか？
「何書けばいいんだっけ…」
「ファイル名とか書いとけばいっか」
「適当に「できました」でいっか笑」
コミットメッセージ、何書いていいかわからない人多いと思います。
そこで今回は僕が実際に使っているコミットメッセージの書き方を紹介します。
GitHubでも見やすく、実際の開発案件・チーム開発でも通用するわかりやすいコミットメッセージが書けるようになれると思います。
※あくまで僕個人の意見です。
コミットメッセージに正解はないので、エンジニアの意見として参考にしていただけたらなと思います。
※実際に使う場合は、ちゃんとチームに確認を取り、必ずチームのルールに従ってください。
コミットメッセージの基本構造
基本的な書式は以下のようになります。
<type>: <subject>
# 例
fix: AAAをBBBに修正
-
<type>: コミットの種類（Prefix）を示します。どんな変更を行ったかを簡潔に表現する、一番重要な部分です -
<subject>: 変更内容を簡潔に説明します
このようにたった2つの要素だけですが、シンプルな形かつ簡潔に作業内容を示すことができます。
Prefixの種類と使い方
<type>はコミットの種類を簡潔に示すワードです。これを活用することで、このコミットがどんな種類なのかが一目で確認できるようになります。
以下に、よく使うPrefixの種類をまとめました。
| type | 説明 |
|---|---|
| feat | 新機能を追加した時 |
| fix | バグを修正した時 |
| docs | ドキュメントのみの変更（READMEなど） |
| style | コードの整形（セミコロン追加、スペース調整など） |
| refactor | コードのリファクタリング(機能を変えないコードの再構成) |
| test | テストの追加や修正 |
| ci | CI/CDの設定や変更 |
| chore | ビルドプロセスや補助ツールの変更 |
| build | ビルドシステムや依存関係の変更 |
たくさんありますが、最初の慣れないうちはfeatやfixだけ使うでもOKです。
このようにPrefixをつけることで、このコミットがどんな種類なのかが一目で確認できるようになります。
ぱっと見でざっくりどんな変更なのかイメージできるのがかなりでかいです。
簡潔でわかりやすい<subject>とは？
typeに続いて書くsubjectは、変更内容を簡潔かつ具体的に記述することが重要です。
たとえば、「fix: バグ修正」と書くのではなく、「fix: ログイン時に発生する無限ループを修正」のように、何に関するバグなのかを具体的に書くことで、他の人が見たときに変更の意図がすぐに理解できます。
そのためのポイントとして僕は、<subject>は50文字以内を目安にしています。
<subject>が長すぎると単純に見にくいというのもありますが、git logなどで表示しきくなってしまいます。変更の概要を短くまとめ流ことができるとスッキリします。
もっと細かい情報をつけたい時は？
ここからは、より詳細な情報をコミットメッセージに含めたい場合の書き方を紹介します。
スコープをつけよう
<scope>は、変更が影響を与える範囲を記述します。これにより、大規模なプロジェクトでもどの部分が変更されたかを把握しやすくなります。(広過ぎたりめんどい場合はなくても大丈夫です)
<type>(<scope>): <subject>
# 例
feat(API): ユーザー情報の取得エンドポイントを追加
このコミットメッセージから、「APIに関する新しい機能が追加されたんだな」と一目で理解できるようになります。
Issueやプルリクに結びつけよう
GitHubなどで開発を進める場合、Issueやプルリクエスト（PR） にコミットを紐づけることはめちゃくちゃ重要です。これができることにより、どのコミットがどのタスクに対応しているのかが明確になります。
<type>(<scope>): #●●● <subject>
(1行空ける)
closes #●●●
# 例
feat(API): #12 ユーザー情報の取得エンドポイントを追加
closes #12
まず<subject>の先頭にIssue番号を入れます。<subject>の後には空行を1行入れ、closes #12のように記述します。これで、このコミットがGitHubのIssue番号12をクローズすることを示しています。
プルリクでも同様にPR番号をいれます。
より詳細な説明をしたい場合
50文字では足らず、変更の理由や背景、具体的な内容などを詳細に記述したいときもあります。その場合は<body>に、なぜその変更を行ったのか、どのような影響があるのかなどを記述するとより親切なメッセージになって理解が深まります。
<type>(<scope>): <subject>
(1行空ける)
<body>
# 例
feat(API): #12 ユーザー情報の取得エンドポイントを追加
ユーザー情報表示画面を実装するにあたり、バックエンドからユーザーデータを取得するためのAPIエンドポイントを追加しました。
これにより、フロントエンド側で`GET /users/{id}`にリクエストを送信することで、指定したIDのユーザー情報をJSON形式で受け取れるようになります。
closes #12
コミットメッセージを書く際のポイント
僕がコミットメッセージを書く時に意識しているポイントを紹介します。
- 一貫性: プロジェクト全体で一貫した Prefix やフォーマットを使用するように心がける
- 具体性: 何を変更したのかを具体的に記述しましょう。「修正しました」だけでなく、「〇〇に関する問題を修正しました」のように記述する
- 簡潔性: 短く分かりやすい言葉で記述する
- 命令形:
<subject>は命令形で記述する - 最初の行を重要視:
<type>(<scope>): #<Issue Number> <subject>は特に重要なので、変更の概要が一目でわかるように記述する
これだけは！
ここまで様々なルールを紹介してきましたが、最も重要なのは「パッと何したかわかる」メッセージにすることです。なのでこれらの厳密なルールを全て暗記・実施する必要はありません。
これらはあくまで良いコミットメッセージを書くためのヒントであって、絶対的な正解ではありません。つまり一番大事なことは簡潔に内容を伝えることだと僕は思います。
また、もっと詳しく知りたい方は、参考にしているConventional Commitsというコミットメッセージの標準ルールをご覧ください。
まとめ
良いコミットメッセージを書くことは、自分自身だけでなく、チーム開発において全体の生産性向上に繋がります。ぜひ紹介した内容を参考に、より分かりやすく、価値のあるコミットメッセージを書いていきましょう！
【最後に告知！】僕が1 on 1でプログラミング教えます！
AI時代に求められる実務スキル & エンジニアのリアルを網羅したカリキュラムを実際の開発案件をもとに作り上げました！今、プログラミングスクールを検討している方で、
- Web開発系エンジニアを目指している
- システムエンジニアを目指している
- AI時代でも活躍できる技術力を身につけたい
そんな人だけを対象とした、エンジニアという仕事に興味を持ち、頑張ってみようと思っているあなたを現役エンジニアが応援・サポートする完全1 on 1スクールですので、こちらもご検討ください！