Gitのコミットログは「読める差分」であるべき

概要

『Software Design』の2020年9月号に掲載されている『ちょうぜつエンジニアめもリーちゃん』の「第4話分けろ!まとめろ!変更差分」というGitの回に、今までのエンジニア人生で、誰からもちゃんと説明してもらったことがなかったことが、たった2Pの漫画でとても分かりやすく書いてあって、とても勉強になったので、感想を記事に書くことにした。

gihyo.jp

学んだこと

Gitのコミットログは「読める差分」になっているべきであって「作業ログ」ではない。
汚いコミットログはrebaseで直す。

今までの私のコミットログに対する理解

エンジニアとして仕事をするようになると、Gitは多くの人がまず最初に覚えることになると思う。

「コミットコメントをちゃんと書こう」というのはエンジニアキャリアを始めた初期の頃から色々な人に言われたが、コミットの粒度に関しては、これまでのエンジニア人生の中でちゃんとした考え方を教わったことはなかった。

そもそもコミットの粒度まではそこまで気にしないっていう人の方が多かったし、これまで担当してきたProjectでも、全体のルールレベルでコミットの粒度に関する指針が示されているケースはなかった。

それでも、チーム開発していると、個人レベルでコミットの粒度を気にする人は時々いて、「コミットログが汚い」的な指摘を受けることは何度かあった。

当時はrebaseでコミットログを修正できるということを知らなかったので、チームの人がコミットの粒度を気にしているのをみたり、私自身がそういった指摘を受けた時には

→ コミットログをきれいにする=実装過程で試行錯誤やミスをしてはいけないということなのか？(私自身は頻繁にコミットする方なので、typoを直したり、変数名がしっくりこなくて直したり、後から見たら実装が納得いかなくて直したりしていると、コミットログは普通に汚くなる。)
→ そんなの自分レベルのエンジニアには無理じゃないか。

という思考回路に陥って混乱していた。

Gitのコミット≒ RPGゲームの「セーブ」？

上述のような経緯から、コミットの粒度について悩んで調べていると、GitのコミットをRPGゲームの「セーブ」の例えで説明している記事をよく見かけた。
これも概ね分かるのだが、3割くらい腑に落ちないところがあった。

というのは、RPGゲームの「セーブ」の場合、やったことがある人は分かると思うが

眠くなった。
習い事の時間になった。
親にもうゲームやめろって言われた。
etc...

などの理由で、ストーリー上では中途半端なところで「セーブ」することが多々あると思う。

だから、必ずしもボスを倒したとか、次の町にたどり着いたとか、そういう区切りのいいタイミングでばかり「セーブ」する訳ではない。

また、そもそもどれくらいの頻度で「セーブ」するかは人それぞれである。

従って、RPGゲームの例えをGitのコミットに適用すると

お昼を食べに行くからコミットする。
退勤するからコミットする。
コミットしたい気分になったからコミットする。
etc...

などがOKということになってしまう。

※ 実際に、過去のProjectでは、休まれたら困るから退勤前にコミット&pushしましょうっていうルールがあって、私自身「退勤するのでコミット」っていうコミットメッセージでコミットしてたことがあった。

でも、上記のようなコミットは、あるべきコミットの姿ではないんだろうな、というのは当時からなんとなく思っていた。

学んだこと

上に書いてきたようなモヤモヤが、『ちょうぜつエンジニアめもリーちゃん』の「第4話分けろ!まとめろ!変更差分」を読んで一気に晴れた。

まず、コミットとは

作業ログ → ×
読める差分 → ○

であるという、非常にすっきりした定義が書いてあって、コミットのあるべき姿を理解できた。

また、今までも、「コミットログがきれいであるに越したことはない」くらいの認識は持っていたけど、「汚いコミットログはきれいに書き変える」っていう問題意識を持ったことはなかったので、従ってrebaseを使う機会もなかった。
(むしろ、コミットログを破壊できる怖いコマンドっていうイメージがあって避けていた。)

でも、これに関しても、featureブランチでの実装過程でコミットログが汚くなるのは全く問題なくて、最後にrebaseでコミットログをきれいにすれば良いというのを知って、rebaseの使い方を覚えようと思った。