Gitのコミット規則

git

心構え

コミット粒度
- きりが良い
- 一文で表せる
- セーブポイントとなりうる

命名規則

<type>(<scope>) : <subject>
feature: A new feature
enhancement: Enhancement existing feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing or correcting existing tests
build: Changes to the build process

`<type>(<scope>) : <subject>`はtypeのためにsubjectをしたという書き方

delete: hogeはたしかにそうなんだけどhogeをdeleteしたという情報しかない
feat: delete hoge なら目的を持って消してる
fix: delete hogeなら何かを直そうとして消してる

きれいなコミットログが理想だが、増えることを気にしてはいけない

無理にきれいに見せるために履歴を編集したり、関心事を多く含めたら本末転倒

commitが汚くなってもいいから、前の履歴を消そうとしない

- 消そうとした理由があるはずだからその理由を残す
- 「導入してやっぱりやめた」と「何もしなかった」は明らかに意味が違う
- この辺のもっともらしい理由もそうだけど
- 消そうとして履歴ぶっ壊す、なんてことも起きるから恥ずかしがらずに消すコミットしような

差分が少ない方が良いのは事実だが、差分を少なくすることを優先してはいけない

「差分」ではなく「関心事」を小さくする。
この変更は何を目的に行われたことなのか？が「関心事」

正しい設計を保つことを目指した結果変更箇所が少なく済むのは悪くないどころかむしろ素晴らしいことですが、「正しい設計を保つこと」と「変更箇所を減らすこと」が対立したときに後者を優先しているとアレ、みたいな話です
https://twitter.com/wonderful_panda/status/1281489105902166023