いつ commit するか？
バージョン管理システムに変更内容を commit*1 するのはいつがベストだろうか？
理想的には、１つの機能を作成または修正したら、その修正内容を沿えて commit をするべきなんだろうが、実際にはなかなかそういうわけにはいかない。
たとえば、あるプロジェクト P のコードを checkout してきて新しい機能を追加するため、関数 newFunc( ) を書き足すとしよう。newFunc( ) の実装は順調で、コンパイルが完了して動作確認を行ったら newFunc( ) についての説明と共に commit する...はずだった。
しかし、動作確認の段階で設計とは異なる結果が返りデバッグを行わなければならない状態になる。そして、不具合は newFunc( ) が呼び出している fooFunc( ) にあることを突き止める。ここで、fooFunc( ) を修正し commit をかけると、１回の commit に newFunc( ) と fooFunc( ) の修正が入ってしまい、理想に対して少し遠くなる。
Ｃ言語や Delphi、Java など多くの言語では、ソースコードを複数のファイルに分割するので、newFunc( ) と fooFunc( ) が違うソースコードに配置される場合には、ファイルを単位としたバージョン管理システムでは問題なく更新することができる。しかし、Java や Visual Basic のようにファイルがプログラム言語の要素と密接に関係するような場合や、Delphi や Visual Basic のような RAD 統合開発環境によって勢いで作成されたような場合など、newFunc( ) と fooFunc( ) が同じファイルに配置されることがあるだろう。
それでは、どうすればいいだろうか？ P を別の場所に checkout しなおして、そこで fooFunc( ) を修正・commit し、改めて newFunc( ) の作業スペースを update し、fooFunc( ) の修正を merge してから commit すべきなんだろうか？
さすがに、それは手間ですよねー（笑）
