コミットコメント

svnのフォルダの話、ソースのコメントの話と来て、今度はコミットコメントについての話題を目にしました。

コミットコメントの書き方 - watawata日記
http://d.hatena.ne.jp/wyukawa/20090918/1253280437

コミットのやり方 - まさたか日記
http://d.hatena.ne.jp/masataka_k/20060820/1156064203

せっかくなので、メモ代わりに自分のやり方を。
基本的にはすべて自己流で、誰かに教えられたり確固とした理由付けがあってしている手順ではないので問題があるかもしれません。ぜひコメント下さい。

コミット時の注意点

• 複数の変更(チケット)を同時にコミットしない

TracなどBTSとsvnをリンクしている場合は、複数のチケットにまたがるようなコミットをしないように注意する。
チケットごとにブランチを切っているような場合は特に問題にならないと思います。

• 変更内容を一度に全部コミットしない

これは一般的じゃないかも。
変更内容によりますが、例えば何か新機能を追加する場合、「新機能に必要な定義、宣言の追加」「新機能の呼び出し部分、インターフェース部分などを追加」「新機能の実体部分を実装」のように、変更時の流れにそってある程度分割コミットしてます。

• 最低でもコンパイルが通る事を確認してコミットする

バグまで潰した上でコミット出来れば良いのですが、実際にはなかなか難しいのでせめてコンパイルだけは通る状態に。

コミットコメントの注意点

• ソースのコメントと同様に「意図」を書く

コミット時にどんな変更をしたのかは差分を見れば一目瞭然なわけなので、
「何のためにこの変更を行ったのか」
「どんな目的でこのコードに変更したのか」
など、差分から読み取れない、読み取りにくい情報をコミットコメントとして付加します。
（私の場合、ソースのコメントにこういった内容がすでに書かれているためコミットコメント自体はソース内コメントの要約になる事も多いです）

• コメントに複数の内容が交じる場合は、コミット内容自体を分割する

一度のコミットでは、一つの事しかやらないように。
コミットコメントを書いていて、複数の項目に分かれるようならコミット自体を分割するようにしています。

実際の流れ

• バグ/追加発生。変更作業のためのブランチ作成(1チケット1ブランチが理想だがsvnだと難しいのである程度まとめて)
• 変更実施。出来るだけこまめにコミット。
• 規模にもよるが数回〜十数回のコミットで作業完了。
• チケットごとに1つずつトランクへマージ。できるだけ、複数チケットの内容を一気にマージしないように注意。

以上、とりあえず思いついたまま書いてみました。