予約語なのに小文字ですね。追加は動作を変更するので分けたほうがいいと思います。この例はさすがに極端なのですが、例えば以下のような変更をするときも2コミットに分けます。ローカル変数にとるようにする」のようなコミットを積んでから変更を積みます。endこれの何がいいかっていうと、レビュアーが楽なんですよね。GitHubのPRにはコミットを順番に見る機能があるので4、リファクタリングって書いてあるコミットは軽く見れます。機能が変わったコミットに集中できます。更新されるのでそれだけでコミットします。したときもそれだけでコミットしてます。db:migrate'モデルとかマイグレいじるときもコミット後に積んだほうが無難かなー。コミットメッセージにいろいろ書く書いておくとGitHubのPRを作るときにもコピペできて便利です。最近だと国内向けのハイフン区切り電話番号の検証をやったのですが、こんな感じのコミットメッセージになりました。意識してるのは、正しい仕様の根拠を示すこと。なにか機能を落としてるなら明記すること。電話番号は以下の仕様となる。ハイフンは市外局番と市内局番の間、市内局番と加入者番号の間にいれる。正しいフォーマットであるといえる。いう検証は今回は行わない...ハイフン区切りの第1項と第2項の桁数の和が必ず6桁であるやらなかったことが明記されてるとあとで助かります。何事もなかったかのように消し去ってます。しとくこれは好みだから別にどっちでも。僕が間違えたことやメソッドの使い方を勘違いしていたことも1つの情報だから、コミットとして残っててもいいのかもなーと思いつつ、blameで遡っていくときの邪魔になるので消しちゃうほうが最近の好みです。1年前だと、「まあ適当で。