バージョン管理ツールを使用したソフトウェア開発では、リポジトリからチェックアウト(クローン）した作業ディレクトリ上でファイルの変更を行います。
1つの作業ディレクトリを継続して使っていたとき
分散バージョン管理を知る前までは、個人の作業ディレクトリは通常1つだけ設け、開発期間中は特段の理由がない限りその作業ディレクトリを使用し続けていました。
- 例）プロジェクトtangoの開発
C:\Users\torutk\tango\dev
このディレクトリで開発し適宜コミットしていきます。そのため、時には1回のコミットで複数のバグ修正を入れてしまうことや、バグ修正と機能開発を同じコミットに入れてしまうことがありました。
ところが、チケット駆動開発を導入すると、バグ修正チケットや機能開発チケット１つ１つにリポジトリの変更が紐付きます。チケットからリポジトリへのリンク（関係しているリビジョン）をたどったとき、そのリビジョン（1回のコミット）に複数のチケットの修正が含まれていると、そのチケットの修正がどれかを特定することが困難（作業者にしか分からない上、作業者も時間が経つと分からなくなる）です。
作業ディレクトリを複数設けるきっかけ
といっても、このことに疑問を抱くようになったのは、開発場所と試験場所が地理的に離れ、かつリポジトリをオンラインで共有できないプロジェクトにおいて、開発場所と試験場所とで修正管理を整合させるため、試験場所に分散バージョン管理ツールを導入したときです。
試験場所では、1つのバグの修正を反映し、再試験を行って結果が良好であれば正式に修正を取り込み、結果が否であれば修正は破棄するという管理をしています。
試験で発見したバグを開発場所で修正した場合、メール等でチェンジセットを添付してもらい、それを1件ずつ反映するため、作業ディレクトリを1件ごとに設けたときからです。こうすると、1つの作業ディレクトリでは1つのチケットの修正を反映するので、チケットとの対応が明確になりました。
作業ディレクトリをチケット単位に別々に設ける
それ以降、特にバグ修正のときは、個人環境においても個別に作業ディレクトリを作るようにしました。
- 例）プロジェクトtangoの開発でバグ#31対応をする
C:\Users\torutk\tango\dev\tango_031
簡単に対応できると思ったバグが予想に反して長期化することもあり、そうしたとき、他の作業と混じってしまうことのないこの方法は効果的でした。
チケット駆動な人達や、分散バージョン管理ツールを使いこなしている人達はすでにこのようなことは習慣となっているのではないかと思いますが、集中型リポジトリを長く使っていて、1つの作業ディレクトリで継続的に開発する習慣が付いてしまった身には新鮮な発見でした。
