はじめに
Gitでコミットする場合はコミットメッセージが必須となります。
※コミットメッセージが空のままで実行するとコミットに失敗します。
このコミットメッセージですが、本当に適当に書いている人が多いです。。。
この記事ではコミットメッセージの重要性と記載方法について記載していきます。
Gitコミットメッセージはなんで記載するの？
まず、コミットメッセージの記載する理由は以下の通りだと考えています。
・一目でどんなコミット内容なのか判断するため
・何故この修正内容になったか理由や意図について簡易的に説明しやすいようにする為
・revertしたい時にどのコミットを対象とするか判断しやすい
→revert自体はあまり推奨されるコマンドでは無いですが、、
・ある時点でどのような修正が入ったか確認したい時に便利
→例えば、
大体この辺りのバージョンから特定のバグが発生するようになった、
では具体的にどのコミットから発生するようになった？
とかの場合に役立つ
・コードレビュー時の差分確認の時に役立つ
不要な修正はコミットすべきで無いので、コミットするからには
必ず修正する理由や意図があるはずです（当然ですが無いならコミットすべきではありませんw）。
そのため、修正する理由や意図を簡潔に一目で分かるような内容にすることが重要です。
記載内容
コミットメッセージに記載する内容としては、以下が挙げられます。
・概要
・原因について記載する
・コミットの理由や意図について
・管理ツールのチケットなどがあるのであれば、チケットのURLを貼ってもOKだと思う
・コミット種別
→コメントでわかるようであれば不要な気もする。
ただし、一目でわかるようにするためには有効だと思うので、シンプルな少ない種別ルールであれば良いと思う
次の項目から、具体的に悪い例/良い例について記載していきます。
悪い例
修正
まず、よく見かけるBadな例です。
何の修正か全く分からない内容となります。
修正と一言で言っても無数にありますよね？
・機能追加のための修正？
・リファクタリングのための修正？
・バグ修正？
・テストコードの修正？
私が過去に見たコミットメッセージで驚いたのは、
"修正"というコミットメッセージで一日に20回ほどコミットしている人がいたことです。
コミットの粒度という点においても不適切ですし、
コミットメッセージを何にも理解していないだろうなと。。
※この人のコードを私がレビューしましたが、チームのコーディングルールを200%無視したマイルールで実装している人でしたね。。
ちなみに、コミットの粒度というのも考えておく必要があります。
というかチームとして各メンバにこの辺りは認識を合わせておく必要があります。
特にレビューしてもらう必要があるのであれば、ある程度の単位（例えば細かくても良いから１機能実装したら１コミットとか）でコミットした方が良いです。
Fix bug
とか
レビュー指摘事項対応
次のBadな例です。
バグをどう直したのか？どういう意図で直したのか？
を知りたいのに、何の意味もないコミットメッセージになっていますよね？
良い例
良いと思われる例をいくつか記載する。
・機能追加
add: xxx画面を追加し、xxx画面から遷移出来るように修正
・バグ修正
fix: hogehoge画面でxxx操作したときに落ちるバグ修正。
原因：xxxの場合にarray index out of bounds
修正内容：配列チェックを追加すると共に、配列範囲外にアクセスしないよう類似チェックをした結果を反映
→バグチケット：https://xxx
・リファクタリング
refactor: hogehoge()メソッドのxxxの処理をxxxに修正
→詳細内容を記載したチケット：https://xxx
あくまで例として記載しましたが、
長すぎるコミットメッセージも良くはありません。
そういった意味ではバグ修正時のメッセージは少々長いですが、、
原因や修正内容を記載しようとするとこれくらいになるんだよなー。
重要なこと
とどのつまり、
自分以外の第三者がコミットメッセージを見て理解しやすい内容になっているかどうか
が重要です。
そのため、第三者が母国語が英語の外人の担当者が見る人が大多数であれば、英語で書いた方が良いです。
余談
これは余談ですが、コミットメッセージに適切なコミットの理由や意図について記載したとしても、
コードやDocコメントなどを見ても修正の意図や理由が分からない場合はその修正内容は不適切なことになります。
当然ですが、この場合はコミットする前に修正内容を見直しましょう。
以上