【ITニュース解説】Work on two branches at once with git worktree

システムエンジニアを目指す初心者の皆さん、Gitを使った開発でこんな経験はありませんか。ある機能の開発に集中している最中に、緊急のバグ修正の依頼が舞い込んできた。開発中のコードはまだ中途半端で、テストも通らない状態だ。しかし、本番環境のバグ修正は待ったなし。そこで、現在の作業を一時的に退避（git stash）し、修正用のブランチに切り替えてバグを直し、コミットしてプッシュする。その後、元の開発ブランチに戻り、退避した作業を復元（git stash pop）する。この一連の流れは「stash dance」と呼ばれ、多くの場合うまくいくが、時には退避した変更と現在のブランチで激しい衝突（コンフリクト）が発生し、未完成のコードの中で解決に苦労することがある。どこが正しい状態なのか分からなくなり、大きなストレスを感じる場面だ。

このような問題は、Gitが長らく「一つのリポジトリにつき一つの作業ディレクトリ（ワーキングツリー）」という前提で設計されていたことに起因する。しかし、2015年にリリースされたGit 2.5で導入されたgit worktreeという機能は、この前提を覆し、一つのリポジトリから複数のワーキングツリーを同時に作成・管理することを可能にした。

git worktreeを使うと、開発中の作業を中断することなく、別のディレクトリに新しいワーキングツリーを作成し、そこで別の作業を進められる。例えば、あなたがfeatureブランチで新しい機能開発を進めているとする。ファイルは変更途中で、まだコミットできない状態だ。そこに緊急のバグ修正依頼が入った場合、次のようにコマンドを実行できる。 git worktree add -b fix-crash ../hotfix origin/main このコマンドは、現在のGitリポジトリにリンクされた新しいワーキングツリーを../hotfixという新しいフォルダに作成する。-b fix-crashは、その新しいワーキングツリーでfix-crashという新しいブランチを作成し、そのブランチをチェックアウトすることを指示する。origin/mainは、fix-crashブランチのベースをリモートのmainブランチの最新の状態に設定することを意味する。これにより、../hotfixフォルダには、バグ修正のためのクリーンな作業環境が即座に用意される。

この新しいワーキングツリーは、メインのリポジトリの完全なコピーではない点が重要だ。両者は同じGitオブジェクトデータベース、同じブランチの定義、同じ設定、同じリモートリポジトリのリストを共有する。「リンクされた」ワーキングツリーなのだ。新しく作成された../hotfixフォルダには、チェックアウトされたソースコードファイルのみが存在し、.gitディレクトリの代わりに、元のリポジトリ内の.git/worktrees/hotfixという場所を指し示す.gitファイルが置かれる。つまり、履歴や設定などのリポジトリの基本的な情報はメインのリポジトリで一元管理され、各ワーキングツリーは「現在どのコミットを見ているか（HEAD）」、「次にコミットする内容（インデックス）」、そして「実際に編集するファイル（ワーキングファイル）」だけを独立して持っている状態になる。

これにより、元のfeatureブランチでの作業を中断したり、退避したりすることなく、別のエディタウィンドウで../hotfixフォルダを開き、緊急のバグ修正作業に取り掛かれる。../hotfixには余分なビルド成果物などは含まれないため、クリーンな状態で迅速に作業を進められる。修正が完了したら、そのワーキングツリーでコミットし、プッシュすればよい。 git -C ../hotfix commit -am "fix: guard null payload" このコミットは、メインのワーキングツリーからもすぐに認識される。同じリポジトリを共有しているため、フェッチなどの操作は不要だ。元のfeatureブランチでの作業環境は一切変更されず、修正途中のファイルや未追跡のノートファイルもそのまま残る。開発サーバーも起動したままで、スムーズに緊急修正と本来の作業を並行して進めることが可能になる。

ただし、git worktreeを利用する上でのルールも存在する。例えば、同じブランチを複数のワーキングツリーで同時にチェックアウトすることはできない。もしfix-crashブランチが../hotfixワーキングツリーで使われている状態で、メインのワーキングツリーでもfix-crashブランチをチェックアウトしようとすると、「'fix-crash' is already used by worktree at '.../hotfix'」というエラーが表示される。これは、もし複数の場所で同じブランチが変更され、片方がコミットされた場合、他のワーキングツリーが参照している履歴が突然変わり、整合性が崩れるのを防ぐための設計だ。ブランチの履歴を追跡する必要がなく、単に特定のコミット時点のファイルが必要な場合は、--detachオプションを使って特定のコミットに紐付けたワーキングツリーを作成することもできる。

git stashコマンドで一時保存した変更は、git worktree環境下でもリポジトリ全体に属するため、どのワーキングツリーからでもアクセスできる。あるワーキングツリーで保存したstashを、別のワーキングツリーから参照したり、適用したりすることも可能だ。ただし、複数のワーキングツリーとstashを併用する場合は、git stash pushの際にメッセージを付けて、どの作業に関連するstashなのかを明確にしておくと、後から混乱せずに済む。

緊急修正作業が完了し、プルリクエストが作成されたら、不要になったワーキングツリーは簡単に削除できる。 git worktree remove ../hotfix このコマンドを実行すると、../hotfixフォルダとそのワーキングツリーに関するリポジトリの記録が削除されるが、fix-crashブランチ自体は削除されずに残る。もし、削除したいワーキングツリーにコミットされていない変更や未追跡のファイルが残っている場合、git worktree removeはエラーを出す。その際は--forceオプションを使うことで強制的に削除できる。 もし、ワーキングツリーのフォルダを手動で削除してしまった場合でも、Gitは対応可能だ。手動削除後は、リポジトリ側にはそのワーキングツリーの記録が「削除可能（prunable）」として残るため、git worktree pruneコマンドを実行することでこれらの残骸をクリーンアップできる。 さらに、USBメモリやネットワーク共有上にあるワーキングツリーなど、一時的にアクセスできない場所にあるワーキングツリーを誤って削除されるのを防ぐために、git worktree lock --reason "on the USB drive" ../usbといったコマンドでロックすることもできる。ロックされたワーキングツリーはpruneの対象外となり、removeしようとしてもロックされた理由が提示されて拒否される。ワーキングツリーの移動もgit worktree moveコマンドで安全に行えるが、メインリポジトリのフォルダを手動で移動した場合は、git worktree repairを実行してリンクを修復する必要がある。

git worktreeは、Gitを用いた開発で複数のタスクを並行して進める際のストレスを大幅に軽減する、非常に強力で実用的な機能だ。これまでは「stash dance」で時間を取られたり、未完成のコードでのコンフリクト解決に頭を悩ませてきた開発者にとって、この機能は大きな助けとなるだろう。一部のGitクライアントはgit worktreeの管理をGUIでサポートしており、さらに手軽に複数の作業環境を切り替えながら開発を進められる。ブランチが「一つのワーキングツリーを順番に使う」という制約は、もはや過去のものだ。現代のシステム開発において、git worktreeを使いこなすことは、より効率的で柔軟な開発フローを構築するための重要なスキルとなる。