#websig1ds の懇親会で会った人が「バージョン管理システムにどのタイミングでコミットしたらいいかわからない」とおっしゃっていて、おれも何度も迷って試行錯誤したけどこういう風にして自分なりにコミット粒度を見極めていきましたよ、という話をしたのでブログにも書いておく。
必要要件は以下
- バージョン管理システム (Subversion, Git) 当然あるはず
- ウェブブラウザでコミット履歴が閲覧できるシステム (Trac, Redmine) これもたいていあるはず
以下手順
- （タイミングがわからなくてもう数日くらいコミットしてないと仮定して）仕事終わりにとりあえず全部コミットする
- 翌朝ウェブブラウザで昨日のコミット履歴を眺める、そのとき以下の点を意識する
- コミットログメッセージを読んで何のコミットだったか思い出せるか？
- 差分をみて何の変更をしたか思い出せるか？
- 「コミットログメッセージが「○○機能の開発」とかざっくりしすぎてて把握しづらい」「機能追加とバグ修正の変更が同じ差分に混じっててわかりづらい」などと感じれば、それが改善のサイン
- コミットログメッセージにより具体的な作業内容を書くようにする（書きづらいならまとまりのわるいコミットをしようとしているサイン）
- 機能追加とバグ修正など、目的の違うコミットを分けて行うようにする（コミット前にも差分をみる習慣をつけるとなおよい）
これだけ。というかこれくらいしかやりようがない。ログメッセージの書き方などはオープンソースソフトウェアのレポジトリなんかも参考になるようだけど、おそらくコミット粒度はぜんぜん違うソフトウェア開発の履歴をみても学びづらいと思う。それに関する書籍やウェブ上の文献もおれは知らない。自分のコミット履歴を読み返すのが一番効果的だと思う。万人向けのコミット作法が身につくわけではないが、少なくとも自分にとっては読みやすい・把握しやすいコミットができるようになる。まず自分が上手にコミットできるようになってから、プロジェクトごとのコミット・ガイドラインを定めたりすればいいと思う。
追記
最近よく issue driven development みたいなことをいわれるけれども、ITS(Issue Tracking System) を積極的に利用するようにして、ITS にチケットを登録し、ticket と commit を関連づけるようにすると、ちょうどいい粒度の感覚が身につくんじゃないかな、とおもった。
ちょうどいい粒度の ticket はちょうどいい粒度の commit にむすびつくのじゃないか。
http://d.hatena.ne.jp/tokuhirom/20110912/1315790179
とりあえず
> 機能追加とバグ修正など、目的の違うコミットを分けて行うようにする（コミット前にも差分をみる習慣をつけるとなおよい）
これはブランチ切るべきかなーと
http://d.hatena.ne.jp/a666666/20110910/1315761292#c1315798516
いずれもおっしゃるとおりだと思うんですが、そういうのは最低限「適当なタイミングでコミットはできてる」のが前提にあるよなーと思っていて、上記のはそれ以前の状態から「コミットすることに慣れる」までを想定して書きました。
ちょうどいいチケットの粒度については、自分でもまだこれ！っていう勘所が見つかってないです・・・。でもあんまり気合入れすぎると続かないので、最近は単なる備忘録くらいのつもりで気軽に、「あ、これはせっかくだからチケット切っとくか」くらいの感じで使ってる。以前なんでもかんでもチケットに細かく切り出しまくりすぎて破綻したことがあるので。
