ゼロから始めるコミットメッセージのススメ

2022年7月29日 08:36

はじめに

こんにちは！SHIFT DAAE(ダーエ) 開発グループ所属の関口です。
いきなりですが、こんなコミットメッセージよく見ませんか？

とりあえずコミット
顧客の名前_漢字にフロントバリデーションを追加
レビュー対応
レビュー対応その２
test

コミットメッセージがおざなりだとレビューする側に立って考えると色々と困る部分が見えてきます。

どんな変更なのか行間を埋めるのにコストがかかったり、コミットメッセージとやったことが一致しているか判断が難しくなります。

逆に、コミットメッセージを少しこだわるだけでより良い開発者体験、チームコミュニケーションが活発になると思います。

ピンときた方は読み進めてみてくださいｗ先人たちが残してくれた知恵がその悩みの少しでもお役に立てればと思います。

Prefixとは何かしらのテキストの先頭につける文字のことです。雰囲気で書いていたコミットメッセージにプレフィックスがあるとパット見で視認性がよくなる。メリットは個人的には以下の3つかと

どのカテゴリの修正か把握しやすい
カテゴリによってロジックに影響ある変更は判断がつきやすい
レビューの濃淡がつけやすく、ロジック変更に注力してレビューができる。スタイルの変更(空白、フォーマット、セミコロン追加など)は少し粒度を下げてフォーマット規約と機械的に比較すればいいのでストレスが減る

何かを実現できる様になる最低単位、もしくはその一部

何かしらの要求に基づいてコードの改修をしているはずなのでその何かを解決する単位がコミットになっていてほしい

冒頭のコミットメッセージの例だと

顧客の名前_漢字にフロントバリデーションを追加
レビュー対応。不要なコードを削除

feat:顧客新規作成機能を追加

よく見るコミットメッセージかと思うが、差分を見ると 全部削除して、全部新規作成みたいな変更になっている

小さいコミットだからと機能追加以外もやってしまうパターンで、よくあるかと思う。

ついでにやって最も罪深いのが、「クラス名変更」や「クラス移動」である。

恐らく見る方は「パッケージがA→Bに移動して、BのTODOだった顧客新規作成部分のメソッドを実装してくれたのね・・・」これが最もレビューの質を落としてしまい、見る方もストレスを感じる

PRの差分は当然同じで全削除、全新規なのだが、このPRはコミット単位でレビューすることが出来る

refactor:クラス移動
refactor:クラス名変更
feat:顧客新規作成機能を追加

レビュー観点とは逸れます。

ぶっちゃけ運用フェーズに入るとプロジェクトで管理しているIDから具体的な修正内容はコード見にいくと思います。※レビュー観点とは別の利用用途がある。コミットメッセージはプレフィクスなどはみるがそこまで読まない。恐らく、実際の修正されているコードを参照することが多くなる。

具体的な対応内容の記載はそこまで重要でないプロジェクトもある。

いかがでしたか？それぞれのプロジェクト状況によってはあまり重要ではないかもしれませんが個人的に良いなとと思っている観点を紹介しました。

＼もっと身近にもっとリアルに！DAAE公式Twitter／

執筆者プロフィール：hiroki sekiguchi
SHIFT DAAE部の開発エンジニア。レビューは切られる覚悟をもってるが切られすぎるとお酒に逃避してしまうかも「つらいときこそ、笑顔」
ばいちゃ！

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/