Git worktreeとは？複数ブランチを同時に扱う便利な機能

こんにちは、とまだです。

Gitでブランチを切り替えるたびに、作業中のファイルをどうしようか悩んだことはありませんか？

機能開発中に緊急のバグ修正が入ってきて、慌ててコミットしたり、stashしたり。そんな経験がある方も多いはずです。

今回は、そんな悩みを解決する「git worktree」という機能について解説します。

この機能を使えば、複数のブランチを同時に扱えるようになります。ブランチ切り替えの手間から解放され、開発効率が格段に上がりますよ。

git worktreeとは？

git worktreeは、1つのリポジトリから複数の作業ディレクトリを作る機能です。

たとえば、図書館で勉強するときを想像してみてください。1つの机で複数の教科書を広げて勉強すると、いちいち本を入れ替える必要があります。

でも、机が複数あれば？数学の教科書は机A、英語の教科書は机Bと分けておけば、すぐに切り替えられますよね。

git worktreeも同じ考え方です。ブランチごとに作業ディレクトリを分けることで、切り替えの手間をなくせるのです。

なぜgit worktreeが必要なのか

通常のGit操作では、ブランチを切り替えるたびにファイルの内容が書き換わります。これには以下のような問題があります。

作業中の変更を一時保存する手間

コミットするほどでもない変更を、毎回stashするのは面倒です。かといって、そのままにしておくとブランチ切り替えができません。

ビルドやインストールのやり直し

node_modulesの再インストールやビルドの実行など、時間のかかる処理を何度も繰り返すことになります。プロジェクトが大きくなるほど、この時間は無視できません。

複数環境の同時確認ができない

バグの原因を調べるときなど、複数のブランチを比較したい場面で不便です。いちいち切り替えていては、効率的な調査ができません。

基本的な使い方

では、実際にgit worktreeを使ってみましょう。

新しいワークツリーを作成する

現在のディレクトリとは別の場所に、新しい作業ディレクトリを作成します。

git worktree add ../hotfix-work hotfix

このコマンドは以下の処理を行います。

• ../hotfix-workという新しいディレクトリを作成
• そのディレクトリにhotfixブランチの内容を展開

実行後は、2つの作業ディレクトリが同じリポジトリを参照している状態になります。それぞれのディレクトリで独立して作業できるようになるのです。

既存のブランチを展開する

すでに存在するブランチを新しいワークツリーに展開できます。

git worktree add ../feature-work feature/login

これでfeature/loginブランチ専用の作業ディレクトリが作成されます。メインの開発を続けながら、別の場所で機能開発を進められます。

新しいブランチを作成しながら展開

まだ存在しないブランチ名を指定すると、自動的に新しいブランチが作成されます。

git worktree add ../new-feature-work -b new-feature

-bオプションを使うことで、明示的に新規ブランチ作成を指定できます。これは通常のgit checkout -bと同じような動作です。

実務での活用シーン

git worktreeが特に役立つのは、以下のような場面です。

緊急対応と通常開発の並行作業

新機能の開発中に本番環境でバグが発生。こんなとき、git worktreeがあれば開発を中断せずに対応できます。

緊急対応用のワークツリーを作成し、そこでバグ修正を行います。修正が終わったら、すぐに開発に戻れます。作業の流れはこうなります。

# 開発中のディレクトリはそのまま
# 緊急対応用のワークツリーを作成
git worktree add ../emergency-fix production

# 緊急対応ディレクトリに移動
cd ../emergency-fix

# バグ修正、テスト、コミット、プッシュ
# ...

# 元の開発ディレクトリに戻る
cd ../main-project

複数機能の同時開発

機能Aと機能Bを並行して開発する場合も便利です。それぞれ専用のワークツリーを用意すれば、コンテキストスイッチがスムーズになります。

エディタのウィンドウを2つ開いて、それぞれ別のワークツリーを表示すれば、まるで2つのプロジェクトを同時に扱っているような感覚で作業できます。

レビューとコーディングの両立

コードレビューのために他の人のブランチを見たい。でも、自分の作業も止めたくない。そんなときも、レビュー用のワークツリーを作成すれば解決です。

レビュー中に気づいた点をメモしながら、自分の開発も進められます。効率的なチーム開発には欠かせない使い方です。

ワークツリーの管理

作成したワークツリーは、適切に管理することが大切です。

ワークツリーの一覧表示

現在どんなワークツリーがあるか確認するには、以下のコマンドを使います。

git worktree list

実行結果の例：

/home/user/project          ab12cd3 [main]
/home/user/project-hotfix   ef45gh6 [hotfix]
/home/user/project-feature  ij78kl9 [feature/login]

このコマンドを実行すると、各ワークツリーのパスとブランチ名が表示されます。定期的に確認して、不要なものがないかチェックしましょう。

ワークツリーの削除

使い終わったワークツリーは削除します。

# ディレクトリを削除
rm -rf ../hotfix-work

# Git側の情報をクリーンアップ
git worktree prune

git worktree pruneは、削除されたディレクトリの情報をGitから取り除くコマンドです。ディレクトリを削除しただけでは、Git側に情報が残ってしまうので、必ずこのコマンドも実行しましょう。

強制削除が必要な場合

ワークツリーに未コミットの変更がある場合、通常の削除ができないことがあります。そんなときは以下のコマンドを使います。

git worktree remove --force ../hotfix-work

ただし、未保存の作業が失われるので注意が必要です。

注意点とベストプラクティス

git worktreeを使う際は、以下の点に注意しましょう。

わかりやすい命名規則

ワークツリーのディレクトリ名は、ブランチ名と関連付けると管理しやすくなります。

良い例

• feature/user-auth → user-auth-work
• hotfix/login-bug → login-bug-fix
• release/v2.0 → release-v2.0

避けたい例

• work1、work2（何の作業かわからない）
• temp（一時的すぎて忘れやすい）

一目で何のための作業ディレクトリかわかるようにしましょう。

同じブランチを複数のワークツリーで使わない

1つのブランチは1つのワークツリーで使うようにしましょう。同じブランチを複数の場所で編集すると、混乱やコンフリクトの原因になります。

もし同じブランチで複数のワークツリーを作ろうとすると、Gitがエラーを出して防いでくれます。

定期的なクリーンアップ

不要になったワークツリーは、こまめに削除しましょう。放置すると、どれが何のためのディレクトリかわからなくなってしまいます。

週に一度はgit worktree listで確認し、不要なものを整理する習慣をつけると良いでしょう。

よくあるトラブルと対処法

git worktreeを使い始めると、いくつかのトラブルに遭遇するかもしれません。

間違ったディレクトリで作業してしまう

複数のワークツリーを扱っていると、どのディレクトリにいるか混乱することがあります。

対策1：プロンプトの設定

プロンプトに現在のブランチ名を表示する設定がおすすめです。多くのシェルで設定可能です。

対策2：作業前の確認

作業前にpwdコマンドで現在地を確認する習慣をつけましょう。また、git branchで現在のブランチも確認すると安心です。

ワークツリーが削除できない

ワークツリーに未コミットの変更があると、削除時に警告が出ることがあります。

必要な変更はコミットするか、不要ならgit reset --hardでクリーンな状態にしてから削除しましょう。どうしても削除したい場合は、前述の--forceオプションを使います。

パスの指定ミス

相対パスと絶対パスを混同して、意図しない場所にワークツリーを作ってしまうことがあります。

作成前にlsコマンドなどで、指定したパスが正しいか確認しましょう。また、タブ補完を活用すると、ミスを減らせます。

まとめ

git worktreeは、複数のブランチを効率的に扱うための便利な機能です。ブランチの切り替えで悩むことなく、それぞれの作業に集中できるようになります。

特に以下のような場面で威力を発揮します。緊急対応と通常開発を並行したいとき。複数の機能を同時に開発したいとき。他の人のコードをレビューしながら開発したいとき。

これらの場面では、git worktreeが大きな助けになるはずです。

最初は管理が少し複雑に感じるかもしれません。でも、使い慣れてくるともう元の方法には戻れなくなりますよ。

ぜひ一度試してみて、開発効率の向上を実感してください。