みなさんこんにちは、かじりです。コミットメッセージを書くときは先頭に大事なことを書くようにしていることについて書きました
参考になった記事1によると、たくさん並んだコミットメッセージを読む時は先頭の２単語くらいしか読まれないということが書いてあった。
私は、自分が実際に対象のコードを探すときに複数のコミットが対象になり、流し読みするときに、確かに先頭の２単語くらいで読み飛ばすと感じた。記事の主張のように、一般的なベストプラクティスと言われているコミットメッセージとは異なるかもしれないが、こちらの方が良いと感じたのでこちらを採用している。
また、githubが公開しているコミットメッセージの作り方2も読んだ。
https://gist.github.com/mono0926/e6ffd032c384ee4c1cef5a2aa4f778d7
こちらはたしか、一般的なこととしてまず無駄なコミットを作らない。例えば自分のコミット中に見つけたtypoを直したみたいなコミットは作らない。
それはいいとして、あとはストーリーを組み立てるべきだと書いてあった。
確かに私もこれに納得して、組み立てるようにしたのだが、どうやっても私の開発スタイルに合わなかった。
例えば、少しのリファクタを行うコミットと、その次に機能追加のコミットを作るとする。これがすんなりいけばいいが、大体うまくいかない。レビューしてもらって、修正したりする時に面倒になる。両方のコミットにまたがる変更だと、rebaseするたびにconflictして、もう、もう、スピードが全く出ない。飽きてくる。なのでまあそれは完全に別物として、リファクタは先にマージする。もしくはあまりリファクタせずに同じコミットに混ぜてしまう。これで1コミットにして扱うことでrebaseしてもコンフリクトは起きないし、平和に高速に開発できる。いやもちろん、developmentブランチに入った変更をrebaseで取り込む時はコンフリクトするけど。まあそれはカウントしない。
他にも例えばこの記事3も読んだ。
ただ、この記事のコミットメッセージ例はベストプラクティスっぽい感じで最近は参考にしていない。
なんかこの雰囲気の記事書いたようなと思ったらすでに書いてた。まあいいか