Git worktreeを使って開発を進める

Git worktreeは、一つのGitリポジトリに対して複数の作業ディレクトリを持つことを可能にする機能だ。これを使うと、異なるブランチでの作業を同時に進めたり、一時的に別のブランチのコードを確認したりするのが非常に楽になる。

基本的な使い方はこんな感じだ。

• 新しいworktreeを作成する: git worktree add <path> <branch> 例えば、 git worktree add ../.working/feature-a feature-a とすれば、リポジトリの親ディレクトリに .working/feature-a という新しいディレクトリが作られ、そこに feature-a ブランチの作業環境が用意される。
• worktreeの一覧を表示する: git worktree list 現在アクティブなworktreeの一覧が表示される。どのディレクトリがどのブランチに対応しているか一目でわかるから、複数の作業を並行している時には重宝する。
• worktreeを削除する: git worktree remove <path> 作業が終わったworktreeはこれで削除できる。物理的なディレクトリも一緒に消してくれるから、手動で削除する手間が省ける。

Gitを使っていると、 branch と worktree という2つの概念が混同されがちだ。でも、僕の中では明確な違いがある。

• branch はコミットへのポインタであり、作業履歴の分岐を管理する。 これは、プロジェクトの変更履歴を論理的に分割するためのものだ。例えば、新機能開発用のブランチ、バグ修正用のブランチといった具合に、コードの進化の道筋を記録する。
• worktree は、一つのリポジトリに対して複数の作業ディレクトリを持つ機能だ。 これにより、異なるブランチでの作業を同時に行えるようになる。例えば、 master ブランチで安定版の作業をしつつ、別の feature ブランチで新機能開発を進める、なんてことが、いちいちブランチを切り替えたり、 stash したりせずにできるわけだ。
• branch はあくまで履歴の管理だが、 worktree は物理的な作業空間を提供する。 ここが一番大きな違いだと僕は思っている。 branch は概念的なものだけど、 worktree は実際にファイルが存在する場所なんだ。

worktreeをどこに置くか、これは結構悩むポイントだと思う。僕も最初は迷った。 とりあえず僕は .working というディレクトリをリポジトリのルートに作成してその配下にworktreeを置いている。こうすることで、複数の作業ディレクトリが散らばらず、管理しやすくなる。

例えば、僕のリポジトリが /home/user/my-repo にあるとして、 feature-a ブランチのworktreeを作るなら、

cd /home/user/my-repo
git worktree add ../.working/my-repo-feature-a feature-a

こんな感じだ。こうすると、 /home/user/.working/my-repo-feature-a というディレクトリができて、そこで feature-a ブランチの作業ができる。元の /home/user/my-repo は別のブランチ（例えば master ）の作業に使える。

GitフローやGitHubフローのような、複数のブランチを頻繁に切り替えて開発を進めるチームにとっては、worktreeは本当に「欲しかった」機能だと感じるはずだ。

• 複数のブランチでの作業を同時に進める際、いちいちstashしたりコミットしたりせずに、作業ディレクトリを切り替えられるのは非常に便利だ。 例えば、 feature ブランチで新機能開発に集中している最中に、急に bugfix ブランチで発生した緊急のバグを修正する必要が出たとする。worktreeがなければ、現在の作業を stash してブランチを切り替え、修正して、また元のブランチに戻って stash を適用して…と、非常に手間がかかる。
• worktreeを使えば、すぐに bugfix ブランチの作業環境に切り替えることができる。 別のターミナルで bugfix 用のworktreeディレクトリに移動し、そこで修正作業を行う。元の feature ブランチの作業はそのまま残っているから、修正が終わったらすぐに元の作業に戻れる。このシームレスな切り替えは、開発の効率を格段に上げてくれる。

僕が今書いているこの文書のリポジトリもGitで管理はしているが、正直なところ、worktreeはあまり必要ない。なぜなら、このリポジトリは非常にシンプルな運用をしているからだ。

• 僕のリポジトリは、基本的に master ブランチに直接コミットしてpushする運用だ。 つまり、ブランチを頻繁に切り替えるような複雑な開発はしていない。一人で作業しているし、機能追加もバグ修正も全て master ブランチで行っている。
• このようなシンプルな運用では、複数の作業環境を必要とすることが少ないため、worktreeの恩恵を受ける機会はあまりない。 worktreeは、複数のブランチで並行して作業を進める場合に真価を発揮する。僕のような単一ブランチ運用では、そのメリットを享受する場面がほとんどないんだ。

世の中には、開発の「やり方」について、ベストプラクティスだのアンチパターンだの、本当にたくさんの情報が溢れている。正直、時々「うるさいな」と感じてしまうことがある。

• それ自体が悪い事ではないけれど、それがあるとそれらに引っぱられた結論になりがちだ。 「これがベストプラクティスだからこうすべきだ」「これはアンチパターンだから避けるべきだ」と、思考停止で適用してしまうのは危険だと僕は思う。
• 自分達が本当に必要なものだけ使い抱えるようにしていった方がいいと僕は思う。 巷には様々な「ベストプラクティス」や「アンチパターン」が溢れているが、それらを盲目的に適用するのは危険だ。チームやプロジェクトの状況、規模、文化によって最適な方法は異なる。
• 大事なのは、自分たちの課題を解決するために、どのツールやプラクティスが本当に役立つのかを見極めることだ。 必要以上に複雑なものを導入すると、かえって開発効率を下げたり、学習コストが増大したりする。
• シンプルさを保ち、本当に必要なものだけを取り入れていく姿勢が、結果的に良い開発につながると僕は信じている。 僕自身、このリポジトリの運用のように、シンプルさを追求している。複雑なツールやプラクティスを導入する前に、本当にそれが必要なのか、自分たちの状況に合っているのかをよく考えるべきだ。