コミットログには"Why"を書け？
よくコミットログには「何をしたか」ではなく「なぜその変更をするのか理由を書け」と言われます。
これは確かに一理あります。
例えば、コミットログに
「登録画面のtitle要素を変更」
などと書かれていたとすると、「いやいや、そんなのはgit log -pすればわかるでしょ。何で変更するのかその理由を書いてよ」と言いたくなります。
そこでチームの規約で「コミットログには理由を書くこと」と定めたとします。
まあよくある話ですね。
そうすると、コミットログはこうなるでしょう。
「SEO対策のために(登録画面のtitle要素を)変更」
さあこれでよいでしょうか？
「理由」を突き詰めると「生きる理由とは？」になってしまう
これは確かに立派な理由かもしれませんが、「ではそれは何のために？」と理由をさらに深堀りする人がいるかもしれません。
- 「なぜその変更がSEO的に有効なのか？」
- 「そもそもなぜSEO対策が必要なのか？」
これらの疑問はもっともです。
コミットログにその理由を書いてみましょう。
「SEOの達人の記事によると、title属性をこう変えた方がSEO的に有利であると書いていたので。また、SEO対策は、ページビューを増やすためには必要であり有効である。」
でもこれにも理由があります。
なんでページビューを増やす必要があるのか？
「業績向上のため」
では「業績向上のため」は何ために？
そうです。
Whyを深堀りすると、「会社は何のために存在するのか？人は何のために生きるのか？」という哲学的な問いに陥ってしまいます。
でもこうなると、「業績向上のためって、それ当たり前じゃないか」という気持ちになってきます。
つまり「コミットログには理由を書け」というポリシーは、それほど自明なものではないのです。
どうするべきなのか
現実的な方法としては、このようにするのがいいのではないでしょうか。
- BTSなどで、やるべきタスクをIssueとして作成する(例：SEOランク向上)
- そこに案件の背景や詳しい理由を書く
- コミットログにIssue番号を書く。 「refs #12345」
- 必要なら、続けて補足的説明を書く。 「refs #12345 登録画面のtitleをこうした方がSEO的に有利なので」
こうすれば、大目的はIssueに書かれているので、コミットログに毎回書かかなくてよくなります。
コミットログには、「Issueや差分には書かれてないこと」だけを書けばよくなります。
Issue番号をいちいち書くのが面倒くさいなら、ブランチ名にIssue番号を含めておいて(dqneo_12345_fix_hogeなど)、コミット時に自動で記録されるようにしておけばよいでしょう。
この方法は、実際に私のチームが現場で毎日実践しており、今のところうまく機能しています。
他によいアイデアなどがあれば教えてください。
それではHappy Committing!