まとめ
DVCSもようやく広まる時期になって来たんでしょうか。だとしたら嬉しいですねー。
パブリックコミット*1とローカルコミット*2をわけて考えて、ローカルコミットに関しては深く考えずに*3やるのがいいと思うのです。軽く速く回せるところは、がんがんまわしたい。回転の力。
「なぜsvnだとxxxだったのがgitだとそうじゃなくなったのか？」と思われるかもしれませんが、たいてい「そうじゃなくなった」ってのは誤解です。新たに選択肢が提示されているだけです。そしてそれを選んだほうがより楽で便利ってだけなんです。svnでも出来なくはないけどゴニョゴニョ……がすんなり出来るとか。先にあるのは解決したい問題で、ツールに振り回される必要はありません。
コミットと変更の粒度
変更理由：コミット の対応の話。
ダメなのは n:1 になっている場合*4で、これは元のブログで書かれている通りです。一つのコミットに複数の変更理由がまとめられているのはNGで、これに対して「1:1 にしよう」はsvnとかだと常識的な話です。
でもgitはコミットの軽さが売りだと思います。複数のコミットは複数まとめてdiffとればいいだけです。一度まとまってしまったものは分けられませんが、バラバラのものをまとめてみることは出来ます。なので「同じ理由で変更されたこと」がわかるようにコミットコメントを書いておけば、無理に 1:1 にする必要はありません。ITS併用でチケット番号とか書いとくといいのでしょうかね。トピックブランチ単位でやれればいいんですけど、gitだとコミットがブランチに紐付かない*5ので、どうしてもコミットコメントに書くことに。
と言うことで変更理由とコミットの関係は 1:n でいくのがいいです*6。1:1 も良いです。
コミット粒度はメンバー間でぼんやりでも認識合わせはしといた方がいいと思います。細かすぎるとか怒るような人もいるかもしれないので、その人に色々教えるのが面倒ならパブリックコミットに関しては 1:1 にしておくのが無難だと思います。
詳細にコミットコメントに書けばいいような気もするかもしれませんが、それだけ詳細に書けるってことは変更理由の粒度が大きすぎる気もしますし、詳細に書くのは時間がかかりますので、もったいないです。
コミットコメントはとりあえずで
ローカルコミット*7のコメントは、短期のものであればgit-nowでいいですが、中期的なものや記憶力に自信がないなどの場合は、それっぽいコメントを深く考えず適当に書いておくのがいいです。ただし自分にはわかるように。適当に。
いざpushする前に、ざーっと他のコミットログを眺めて、そのリポジトリでのコメントの雰囲気にあわせてコメントをつけ直す感じでやります。例えばこんなコミットログは嫌ですよね？
e1658a3 機能Aを追加 fb6ae9f Merge branch 'hoge' into master c51ab60 [バグ修正]yyyとzzzを修正 f9958a3 add bbbb method ccd2dda 2012/08/31 temp 9101f63 fixed Issue 99: xxxxの不具合 b42e10e jenkinsが怒ったのでリバート
ようするに、コミット単位ではそれなりに考えて書いているかもしれないけど、なんか整合性とれてないの。これだと変なコミットが混じる確率が上がります。混じってても気づきません。混じってたからどーなんだってのは別の議論。
私はコミット一つ一つでいちいちコメントに悩むのは勿体ないと思ってます。後から清書する時に備えて、適当に書くべきとは思うのですが、毎回いちいち悩んで立ち止まっちゃってたら進むものも進みません。なのでローカルコミットは気軽に書いて、pushする前にまとめて考える。*8
リポジトリ全体のコミットログの整合性となると、gitのコミットコメントは遡って別のものにすることは出来ますが、変えた以降が別のコミットになるので嬉しくないし、メンドクサイのでそこまでする必要はないかなと。でも、せめてpushする数コミット単位で、直近数十件のコミットコメントを俯瞰して、そのリポジトリでのルールも踏まえて、それっぽく書くのが良いんじゃないかなーなんて思ってます。
まとめ
最初に書いた。
