コミットの粒度

コミットの粒度に関して、とても参考になる記事があったのでリンクしておく。

【元ネタ】
git commit するまえに考えるべき10のこと | Act as Professional - hiroki.jp by HIROCASTER

「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組

GitやMercurialがCVSやSVNよりも優れている点は、ブランチ管理の容易さと豊富なマージコマンド。
特に、ローカルにブランチを作り、プライベートなブランチとして開発者は好き放題にコミットすればいい。
そして、masterに最終的にコミットする時、必要なパッチのみまとめて送ればいい。

コミット履歴を改変する必要があるのは、masterのコミット履歴を綺麗にする場合だろう。
ローカルのブランチは自分だけが好きなようにコミットしてもいいが、masterのコミット履歴は、その変更意図が分かるような歴史で残すようにしたい。
特に、ソース管理が一人だけの開発者ではなく、大規模システムで複数人の開発者の出入りが激しい場合、ソース管理のコミット履歴はとても重要な情報になる。

「No Ticket, No Commit」はあまりにも厳しいルールという批判を受ける時がある。
コミットする時に逐一チケット番号を書くのは面倒で、プログラミング速度が落ちる、と。

そもそも「No Ticket, No Commit」のルールは、障害管理における変更履歴を残す所から生まれた背景がある。
つまり、障害管理をきちんとしなければならないようなシステム開発であり、開発者がずっとシステムの面倒をみるプロジェクトではない。
ソースは一人だけの開発者の物ではなく、プロジェクトに関わる全員の物だ。
XPのソースの共同所有はそういう発想なのだろう。

だが、皆が関わるブランチ(master)は「No Ticket, No Commit」を守る方が運用保守ではとても効果的だが、ローカルのプライベートブランチまで必要かどうかは言ってはいない。
プライベートブランチは開発者一人だけの物であり、最後に必要なパッチを送る時に、チケット番号も一緒に送ればいいだけだ。

SVNのコミットログの書き方: プログラマの思索にも書いたけれども、特にプログラミング初心者はコミットログを意識して書くようにした方がいい。
そうすれば、コミットの粒度がとても明確になる。
コミットの粒度はよく迷うが、チケットの粒度の考え方と同じ。
コミットの粒度も小さい方がやりやすいが、意味ある大きさでコミットしなければ、逆にコミットが面倒になる。

以前、@yusuke_kokuboさんが、RedmineのメインコミッタであるJPLはコミットの粒度がよく考えられている、と言われていて、なるほどと思う時があった。

Twitter / yusuke_kokubo:RedmineのリポジトリをウォッチしてるとJPLのコミットの粒度の適切さに感心する。Redmineの使い方はredmine.orgに学ぶことが多い。(それにくらべてBacklogsプラグインは…ゴニョゴニョ)
返信 リツイート お気に入りに登録

また、No Ticket, No Commitの効果: プログラマの思索にも書いたけれども、昔のソースほど、無駄なコメントがソースにガラクタのように残っている。
チケット駆動開発でソース管理しているならば、ソースから最終的には全てのコメントは消えて、ソースは必要最低限の機能を実装するものになると思う。
つまり、プログラムの途中で仕様を説明したいならば、コミットログにチケットNoを貼り付けておき、チケットを参照するようにすればいい。
ソースに更新履歴や仕様を説明したコメントは不要だ。

すると、SCMコミットログはファイルのメタ情報: プログラマの思索にも書いたが、コミット履歴は最終的にはソースのメタ情報になる。
つまり、チケットやリポジトリのコミットログは、変更履歴の全文検索の対象であり、ソフトウェア開発の資産(ナレッジ)そのもの。

ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する: プログラマの思索にも書いたが、ApacheやEclipseのリポジトリのコミットログから、意味ある経験知を見出そうと研究するソフトウェア・リポジトリ・マイニングというソフトウェア工学の手法もある。
こういう研究が可能になったのも、バージョン管理ツールが普及し、オープンソースのツールが商用ツールに匹敵するほど量も質も良くなってきたことがあげられるだろう。

面白い時代だと思う。