git commit のタイミング
git で commit するタイミングについて自分の中で程よいものが見つかったので記録として残しておきます。
タスクを作る
まずは何を作るか、できるだけわかりやすい、程よい量のタスクを作ります。このタスクを解決できるようにソースを改変してコミットするというのが出発点です。
github/gitlab なんかで Issue を作れば番号で管理できるのでいいですね。git hook を使うと番号を入れない限り commit 出来ないようにすることもできるので、だらだらとソースをいじったり、いろいろ試しているうちに何の変更をやってるかわからなくなるということがなくなりました。
revert する場面を想像する
自分が作ったコミットが将来バグになってしまった場合、まるっと戻したくなることがあります。一番楽なのは revert してもきちんと動くソースになること。
なので、特にパッチを作るときには revert できる単位でコミットすると後々自分を救うことになります。
いろいろ試したいとき
使ったことのない機能を試したいときなどは、Try and error が続くのでコミットするタイミングがわからなくなります。いくつか解決方法があると思いますが、ブランチを切るか stash を使うのがいいです。
ブランチを切る
ある程度、大きな変更が起こりそうとか、まったくテスト目的だけで将来放置するか捨てることが決まっているのであれば、ブランチを切るのがいいです。テストがうまくいけばマージすればいいし、うまくいかなければブランチごと削除すればいいですね。
stash を使う
小さな変更で試せる内容であれば stash がおすすめです。stash で一時保管すればまた最初からやり直せるし、必要なものはいつでも取り出してマージすることもできます。
でも「コミットのタイミング」というわけではないですが・・・(汗)
squash する
ちまちまと commit を作ってしまっても squash (git rebase -i) すればきれいにまとめることができます。部分的に変更するような場合は、作業の区切りに合わせてどんどんコミットするというのもありです。squash できると思ったら気軽に commit も出来ちゃいますね。
ただし、push のタイミングは気をつけましょう。
コミットログに説明できる変更内容にする
いくつかのバグをひとつのコミットにしてしまったり、小さな単位でコミットしたり、タイポを直したり。そういった場合、コミットログを書こうと思っても変更内容をうまくコミットログに書くことができなくなるはずです。
ソースを変更しながら、「これはコミットログで説明できるやりかただろうか」というのを自問自答しつつ、変更の規模をコントロールしてコミットログをきれいに書いてあげましょう。コミットするタイミングではなく、コミットのためにどう変更するかという考え方になります。
まとめ
思いつくところを書きましたが、最低限必要なのはタスクを作ることだと感じています。うまく行くと、タスクの内容がそのままコミットログになるし、revert も綺麗にできるのでとても気持ちいです。
ほどよい量のタスクをデザインするのが難しいところがまた問題なのですが。。。
Discussion