【Git】git worktree とは？初心者向けにわかりやすく解説
はじめに
Gitはコードのバージョン管理を行うためのツールです。 チーム開発や個人プロジェクトでも、変更履歴の管理を効率化するために多くの人が利用しています。
ただ、ブランチを切り替えながら作業をする場面は多く、時には複数のブランチを同時に行き来したいこともあるでしょう。 しかし、通常の方式ではブランチをチェックアウトするたびにステージや作業ディレクトリを切り替える必要があります。
そうした作業の煩雑さを軽減する機能の一つがgit worktreeです。 複数の作業用ディレクトリ（ワークツリー）を用意して、必要に応じてブランチを並行して管理できます。 これにより、ブランチの切り替え待ちが少なくなり、開発効率を上げられるのが魅力です。
今回は、初心者の方にもわかりやすいように、git worktreeの概要から基本的な操作方法、実務でどんなふうに活用できるかまでを順番に説明していきます。
この記事を読むとわかること
- git worktreeの仕組みとメリット
- 複数ブランチを並行管理する具体的な手順
- 実務での活用シーンと注意点
- コード例（コマンド例）を通じた操作イメージ
これらを理解することで、ブランチ管理がスムーズになり、複雑な機能追加やバグ修正も行いやすくなるでしょう。
git worktreeの概要
git worktreeは、単一のGitリポジトリを複数の作業ディレクトリで扱う仕組みを提供します。 従来の方法では、あるブランチで作業を行う際にgit checkoutを使ってブランチを切り替えますが、ブランチによってコードの実装が大きく異なる場合、何度もファイルを切り替える手間が生じます。
git worktreeを使えば、同じリポジトリに紐付いた複数の作業用ディレクトリを作成し、それぞれで別のブランチを展開できます。 まるで複数の「作業場所」が用意されるような感覚です。
どうして複数のワークツリーが役立つのか
複数のワークツリーを使えば、並行しているタスクをスムーズに切り替えることが可能になります。 例として、以下のようなシチュエーションを考えてみてください。
- バグ修正用のブランチと新機能の開発ブランチを同時に扱いたい
- 機能Aと機能Bを同時進行しているが、どちらも時間をおかずに更新の必要が出てくる
通常のブランチ切り替えでは、作業途中のファイルをコミットしたり、ステージした変更を取り消したりと手間がかかります。 ワークツリーを使えば、それぞれのブランチが独立した作業ディレクトリ上に展開されるため、ファイルが混在することはありません。 そのまま並行して作業ができます。
実務で役立つシーンの例
実務でも、運用中のサービスへの緊急修正と新しい機能の開発が重なるケースは多いものです。 git worktreeを使っておけば、緊急対応のブランチと新機能開発ブランチをそれぞれ独立したディレクトリに展開しておけます。 バグ修正が完了したら、再度チェックアウトをしなくても、すぐに新機能開発の作業ディレクトリに戻ることができます。
仮に複数のプロジェクトが並行する状況でも、同じリポジトリ内でブランチを複数展開できるので、余計な操作を減らせます。 このようにgit worktreeは、効率的にブランチ管理を行いたいときに非常に便利です。
git worktreeの基本的な仕組み
git worktreeは、リポジトリの.gitフォルダを共有する形で新しい作業ディレクトリを作ります。 リポジトリのルートディレクトリ（.gitがある階層）と、worktreeコマンドで作成した新しいフォルダは、同じリポジトリ情報を指し示すイメージです。
単独で複数のリポジトリをクローンしているわけではなく、1つの.gitフォルダを中心に複数のワークツリーを展開しています。 つまり、もしリポジトリを巨大な倉庫と考えるなら、同じ倉庫を参照しつつ、作業場だけを増やすような形です。
メリット
- 切り替えの手間が軽減：ブランチをチェックアウトするたびにファイルの変更を巻き戻す必要がない
- ディスク容量の節約：フルクローンを何度も作成するわけではないため、重複したリポジトリが増えにくい
- コンテキスト切り替えの効率化：緊急対応や並行作業のときでも、スムーズにタスクを行き来できる
デメリット
- 管理が増える：複数のディレクトリが存在するため、どのフォルダがどのブランチなのかを意識する必要がある
- 上書きリスク：間違ったフォルダに入って変更を加えてしまうと、意図せぬブランチに作業してしまうこともある
複数の作業ディレクトリを作るときは、フォルダ名をわかりやすくするなどの工夫が大切です。
git worktreeを使った基本操作
それでは、git worktreeの代表的な使い方を見てみましょう。 ブランチを追加し、新しいワークツリーを作成する手順をコード例（コマンド例）で紹介します。
ワークツリーの追加
まず、現在のリポジトリに紐付いた作業ディレクトリを追加します。 以下のようにコマンドを使うことが一般的です。
git worktree add ../feature-worktree feature-branch
../feature-worktreeは新しいワークツリーとして作成するフォルダ名です。相対パスや絶対パスで指定できます。feature-branchは新しいワークツリーに対応させたいブランチ名です。
もし指定したブランチがまだ存在しない場合は、自動的に新規ブランチが作られる仕様になっています。 たとえば次のコマンドでブランチが新しく作られます。
git worktree add ../new-feature new-feature
これにより、../new-feature というフォルダが作成され、そこがブランチ new-feature の作業ディレクトリになります。
既存ブランチをワークツリーに追加する
作成済みのブランチを別のワークツリーに展開したいケースでは、同じようにコマンドを使って指定します。
たとえば以下のように既存の hotfix ブランチを展開できます。
git worktree add ../hotfix-worktree hotfix
このコマンド実行後、../hotfix-worktree フォルダの中身は hotfix ブランチの内容になります。
他の作業ディレクトリでは develop ブランチや feature-branch をいじっていても、ここでは hotfix の変更だけが反映されています。
実務での活用例
では、どのような手順で実務に活かせるのか、流れを簡単にまとめてみます。
- メイン開発ブランチ：通常はメインの開発ブランチ（例：develop）を操作しているディレクトリで機能Aを開発する
- 緊急修正の発生：運用中のバージョンでバグが見つかったため、緊急修正のブランチ（hotfix）を切りたい
- 別のワークツリーを作成：
git worktree add ../hotfix-worktree hotfixのコマンドで別ディレクトリを用意する - 修正作業完了：
hotfixブランチにコミットやプッシュをして修正が完了したら、再度developブランチに戻る必要なし - タスク切り替え：本来作業していた
feature-Aブランチのワークツリーに移動し、続きの作業を再開する
こんな流れで複数ブランチが同時進行になっても、メインブランチへ移動する手間がなく、必要に応じてワークツリーを行き来できるのです。
コード例: 複数ブランチでの並行作業
# リポジトリクローン済みで、現在のディレクトリが /myproject とする # 1. 通常の develop ブランチで作業中 cd /myproject # 2. hotfixブランチ用のワークツリーを追加 git worktree add ../myproject-hotfix hotfix # 3. ここで myproject-hotfix ディレクトリに移動して修正 cd ../myproject-hotfix # ファイル修正、コミット、プッシュなどを行う git add . git commit -m "Fix urgent bug" git push origin hotfix # 4. 修正が終わったら、developブランチのmyprojectディレクトリに戻り続きの作業を行う cd ../myproject # ここではすでに develop ブランチの内容が用意されているので、作業を継続できる
このように、ワークツリーごとにブランチが独立しているので、並行作業が非常に楽になります。
ワークツリーの削除やクリーンアップ
不要になったワークツリーを放置しておくと、どのディレクトリが何のために存在していたのか分からなくなります。 そこで、使い終わったワークツリーは削除やクリーンアップを行いましょう。
ワークツリーの削除
単純に作成したフォルダを削除し、その後に git worktree prune を実行すると、不要なエントリがリポジトリ上からも消える仕組みです。
# ファイルシステム上で削除 rm -rf ../myproject-hotfix # Git側の不要情報を削除 git worktree prune
git worktree prune は、すでに存在しないワークツリーに関する参照をGitが掃除してくれるコマンドです。
ワークツリーが増えたらこまめにチェックし、終わったものは整理すると管理しやすくなります。
誤ってまだ必要なワークツリーを削除しないよう、ディレクトリ名やブランチ名をこまめに確認してください。
使う際の注意点
いくら便利とはいえ、複数のワークツリーが増えすぎると混乱を招く可能性があります。 次の点に注意しながら運用すると、よりスムーズに活用できるでしょう。
フォルダ名の工夫
ブランチ名と関連づけがわかりやすいフォルダ名をつけるのがおすすめです。
たとえば、hotfix-login-bug など明示的にしておくと、自分やチームメンバーが見ても目的がはっきりします。
作業ブランチをこまめにマージ
ワークツリーをいくつも作ったまま放置すると、古いブランチと新しいブランチが大量に同時存在する状態になります。 完了したブランチはメインブランチにマージし、作業ディレクトリを削除することで、管理をシンプルに保つことが可能です。
コンフリクトの取り扱い
仮に複数のワークツリーで同じファイルを変更している場合、コンフリクトが発生する可能性もあります。 コンフリクトが起きそうな変更を同時進行するなら、どのブランチを優先するか、あらかじめチームで合意しておくとトラブルを防ぎやすいでしょう。
ワークツリー管理の実務への応用
worktreeは、複数のブランチを同時に触る必要がある場面で大いに活躍します。 例えば、機能A・機能Bの実装が進んでいる最中に、小さな改修や調整が舞い込んだ場合にも、それぞれの作業環境をすぐに切り替えられるのがメリットです。
実際に作業を行うエンジニアの視点から見ても、画面を複数開いておき、別々のディレクトリでコードを動かせるため、確認作業が楽になります。 また、別々のブランチを同時に検証したいときも、いちいちブランチをチェックアウトし直さずに済むので開発のテンポがよくなることが多いです。
よくあるトラブルと解決策
初心者の方がワークツリーを使い始めると、どのブランチがどのフォルダか分からなくなったり、間違った作業ディレクトリでコミットしたりといったミスが発生しがちです。
ブランチ名とフォルダ名が食い違う問題
ワークツリーを作る際に、ブランチ名と同じ名前のフォルダを用意しておけば混乱を減らせます。
どこが何のブランチか分からない問題
git worktree list コマンドを実行すると、どのフォルダに何のブランチが紐づいているかを一覧表示できます。定期的に確認すると良いでしょう。
git worktree list の出力例
$ git worktree list /path/to/myproject d7f3b34 [develop] /path/to/myproject-hotfix a9b8c12 [hotfix] /path/to/myproject-new-feature f2d1e78 [new-feature]
上記のように、各ディレクトリとブランチが確認できます。 どれを消していいか、どのブランチを作業中か、ひと目で分かるので便利です。
よくある質問
ワークツリーの数に上限はある？
特に明示的な上限はありませんが、あまりに増やしすぎると管理が大変です。 目的に応じて必要最低限のワークツリーを作り、不要になったら削除すると運用しやすいです。
一度に複数のワークツリーで同じブランチを使えますか？
同じブランチで複数のワークツリーを並行して使うことは基本的に避けた方がいいです。 衝突やコンフリクトを招きやすいため、ブランチはワークツリーと一対一で管理するのがおすすめです。
まとめ
git worktreeは、ひとつのリポジトリを複数の作業ディレクトリとして展開できる、とても便利な機能です。 特に、並行して作業すべきブランチが複数あるときに、大きく効率を上げてくれます。
作成も削除もコマンドひとつで行えますし、ワークツリーをうまく活用すれば、バグ修正や新機能開発の切り替えがスムーズになるでしょう。 その一方で、複数フォルダを同時に管理するわけですから、フォルダ名とブランチ名の対応づけや不要になったワークツリーのクリーンアップは欠かせません。
初心者の方にとって、ワークツリーははじめ見慣れない概念かもしれませんが、使いこなせるようになれば日常の開発効率が向上します。 少しずつ試しながら、複雑なブランチ運用に悩まされない開発環境を作ってみてください。