ゼロから始めるコミットメッセージのススメ
はじめに
こんにちは!SHIFT DAAE(ダーエ) 開発グループ所属の関口です。
いきなりですが、こんなコミットメッセージよく見ませんか?
とりあえずコミット
顧客の名前_漢字にフロントバリデーションを追加
レビュー対応
レビュー対応その2
test
コミットメッセージがおざなりだとレビューする側に立って考えると 色々と困る部分が見えてきます。
どんな変更なのか行間を埋めるのにコストがかかったり、 コミットメッセージとやったことが一致しているか判断が難しくなります。
逆に、コミットメッセージを少しこだわるだけでより良い開発者体験、チームコミュニケーションが活発になると思います。
この記事のターゲット
チームでgitを使っている
チームでコミットルールを理解、改善したい方
よりよい開発者体験につなげたい
日々のストレスからせめてレビューくらいはストレスを受けたくない
ピンときた方は読み進めてみてくださいw 先人たちが残してくれた知恵がその悩みの少しでもお役に立てればと思います。
まとめ
Prefixをつける
コミットは実現した事単位で行う
1つのコミットで1つを行う
1. Prefixをつける
Prefixとは何かしらのテキストの先頭につける文字のことです。 雰囲気で書いていたコミットメッセージにプレフィックスがあると パット見で視認性がよくなる。 メリットは個人的には以下の3つかと
どのカテゴリの修正か把握しやすい
カテゴリによってロジックに影響ある変更は判断がつきやすい
レビューの濃淡がつけやすく、ロジック変更に注力してレビューができる。スタイルの変更(空白、フォーマット、セミコロン追加など)は少し粒度を下げてフォーマット規約と機械的に比較すればいいのでストレスが減る
2. コミットは実現した事単位で行う
何かを実現できる様になる最低単位、もしくはその一部
何かしらの要求に基づいてコードの改修をしているはずなので その何かを解決する単位がコミットになっていてほしい
冒頭のコミットメッセージの例だと
顧客の名前_漢字にフロントバリデーションを追加
レビュー対応。不要なコードを削除
3. 一つのコミットで一つを行う
feat:顧客新規作成機能を追加
よく見るコミットメッセージかと思うが、差分を見ると 全部削除して、全部新規作成みたいな変更になっている
小さいコミットだからと機能追加以外もやってしまうパターンで、 よくあるかと思う。
ついでにやって最も罪深いのが、「クラス名変更」や「クラス移動」である。
恐らく見る方は「パッケージがA→Bに移動して、BのTODOだった顧客新規作成部分のメソッドを実装してくれたのね・・・」 これが最もレビューの質を落としてしまい、見る方もストレスを感じる
PRの差分は当然同じで全削除、全新規なのだが、このPRはコミット単位でレビューすることが出来る
refactor:クラス移動
refactor:クラス名変更
feat:顧客新規作成機能を追加
おまけ
レビュー観点とは逸れます。
ぶっちゃけ運用フェーズに入るとプロジェクトで管理しているIDから具体的な修正内容はコード見にいくと思います。※レビュー観点とは別の利用用途がある。コミットメッセージはプレフィクスなどはみるがそこまで読まない。恐らく、実際の修正されているコードを参照することが多くなる。
具体的な対応内容の記載はそこまで重要でないプロジェクトもある。
終わりに
いかがでしたか? それぞれのプロジェクト状況によってはあまり重要ではないかもしれませんが 個人的に良いなとと思っている観点を紹介しました。
\もっと身近にもっとリアルに!DAAE公式Twitter/
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/