複数のブランチを同時に開発したい。そんなとき、従来は git checkout でブランチを切り替えながら作業していましたが、頻繁な切り替えは非効率ですし、ビルド成果物の再生成も時間がかかります。そこで登場するのが Git worktree です。この機能を使えば、1 つのリポジトリから複数のブランチを別々のディレクトリに展開し、並行して作業できます。

この記事では、Git worktree の基本から実践的な使い方まで、最短で習得できるように解説します。

背景

Git で開発を進める際、1 つのリポジトリで複数のタスクを並行して進めたい場面は頻繁に訪れます。たとえば、新機能を開発中に緊急のバグ修正が入ったり、レビュー待ちのブランチがある中で次の開発に着手したりといったケースです。

従来の方法では git checkout でブランチを切り替えて対応していましたが、この方法にはいくつかの課題があります。

以下の図は、従来のブランチ切り替え方式と Git worktree を使った並行開発の違いを示しています。

mermaidCopy codeflowchart TB
  subgraph traditional["従来の方法"]
    repo1["リポジトリ"]
    branch1["feature ブランチ"]
    branch2["hotfix ブランチ"]
    repo1 -->|checkout で切り替え| branch1
    repo1 -->|checkout で切り替え| branch2
  end

  subgraph worktree["Git worktree の方法"]
    repo2["メインリポジトリ"]
    dir1["ディレクトリA<br/>feature ブランチ"]
    dir2["ディレクトリB<br/>hotfix ブランチ"]
    repo2 -->|同時に展開| dir1
    repo2 -->|同時に展開| dir2
  end

この図から分かるように、Git worktree を使うと、1 つのリポジトリから複数のブランチを別々のディレクトリとして同時に扱えるようになります。

課題

git checkout によるブランチ切り替えには、以下のような課題があります。

作業状態のリセットが必要

ブランチを切り替える際、作業中の変更をコミットまたはスタッシュする必要があります。中途半端な状態で切り替えられないため、作業の流れが途切れてしまいます。

ビルド成果物の再生成コスト

node_modules や dist などのビルド成果物は、ブランチによって内容が異なる場合があります。切り替えのたびに yarn install や再ビルドが必要になり、待ち時間が発生します。

エディタや IDE の設定リセット

VSCode などのエディタは、開いているファイルやタブの状態を保持しています。ブランチを切り替えると、これらの状態がリセットされ、再度ファイルを開き直す手間が発生します。

複数タスクの切り替えコスト

緊急対応と通常開発を並行したい場合、頻繁な切り替えは思考の中断を招き、生産性が大きく低下します。

以下の図は、ブランチ切り替え時に発生する課題を整理したものです。

mermaidCopy codeflowchart TD
  start["ブランチ切り替え開始"]
  stash["作業中の変更を<br/>スタッシュ"]
  checkout["git checkout 実行"]
  rebuild["依存関係の<br/>再インストール"]
  reopen["エディタでファイルを<br/>再度開く"]
  resume["作業再開"]

  start --> stash
  stash --> checkout
  checkout --> rebuild
  rebuild --> reopen
  reopen --> resume

  style rebuild fill:#ffcccc
  style reopen fill:#ffcccc

この図のように、ブランチ切り替えには複数のステップと待ち時間が伴います。赤色で示した部分が特に時間のかかる工程です。

解決策

Git worktree は、これらの課題を根本的に解決する機能です。1 つのリポジトリから複数のブランチを別々のディレクトリに展開することで、同時並行で作業できるようになります。

Git worktree の仕組み

Git worktree は、同一リポジトリの異なるブランチを別々の作業ディレクトリとして管理します。各ディレクトリは独立しており、それぞれで異なるブランチをチェックアウトした状態を維持できます。

以下の図は、Git worktree の内部構造を示しています。

mermaidCopy codeflowchart TB
  subgraph main_repo["メインリポジトリ .git"]
    git_dir["Git データベース<br/>（共通）"]
  end

  subgraph work1["worktree-1 ディレクトリ"]
    branch1["feature/login"]
    files1["ソースコード"]
    build1["node_modules"]
  end

  subgraph work2["worktree-2 ディレクトリ"]
    branch2["hotfix/bug-123"]
    files2["ソースコード"]
    build2["node_modules"]
  end

  git_dir -.参照.- work1
  git_dir -.参照.- work2

各 worktree は独立した作業領域を持ちながら、Git のデータベース（オブジェクトストレージ）は共有します。これにより、ディスク容量を節約しながら並行開発が可能になります。

Git worktree の主な利点

以下の表で、Git worktree の利点を整理します。

#	利点	説明
1	並行作業	複数のブランチを同時に開いて作業可能
2	状態の保持	各ブランチの作業状態を独立して維持
3	切り替え不要	ディレクトリ移動だけで済み、checkout 不要
4	ビルド成果物の維持	各 worktree でビルド結果を保持できる
5	ディスク効率	Git オブジェクトは共有され、容量を節約

基本的な使い方

Git worktree の基本的なコマンドを見ていきます。

新しい worktree の作成

新しいブランチを別ディレクトリに展開するには、git worktree add コマンドを使います。

bashCopy code# 既存のブランチを新しいディレクトリに展開
git worktree add ../feature-login feature/login

このコマンドは、..​/​feature-login というディレクトリに feature​/​login ブランチを展開します。

bashCopy code# 新しいブランチを作成しながら worktree を追加
git worktree add -b feature/payment ../feature-payment

-b オプションを使うと、新しいブランチを作成しながら worktree を追加できます。

worktree の一覧表示

現在存在する worktree の一覧を確認するには、git worktree list を使います。

bashCopy codegit worktree list

このコマンドは、以下のような出力を返します。

bashCopy code/Users/username/project              abc1234 [main]
/Users/username/feature-login        def5678 [feature/login]
/Users/username/hotfix-bug           ghi9012 [hotfix/bug-123]

各行には、ディレクトリパス、コミットハッシュ、ブランチ名が表示されます。

worktree の削除

不要になった worktree を削除するには、まずディレクトリを削除してから git worktree prune を実行します。

bashCopy code# worktree ディレクトリを削除
rm -rf ../feature-login

bashCopy code# Git の管理情報をクリーンアップ
git worktree prune

あるいは、git worktree remove コマンドで一度に削除することもできます。

bashCopy codegit worktree remove ../feature-login

具体例

実際の開発シーンを想定して、Git worktree の使い方を具体的に見ていきます。

シナリオ：新機能開発中に緊急バグ修正が発生

あなたは現在 feature​/​user-profile ブランチで新機能を開発中です。そこに緊急のバグ修正依頼が入り、hotfix​/​critical-bug ブランチでの対応が必要になったとします。

以下の図は、このシナリオでの作業フローを示しています。

mermaidCopy codesequenceDiagram
  participant dev as 開発者
  participant main_wt as メイン worktree<br/>feature/user-profile
  participant hotfix_wt as Hotfix worktree<br/>hotfix/critical-bug

  dev->>main_wt: 新機能を開発中
  Note over dev: 緊急バグ修正の依頼
  dev->>dev: git worktree add でhotfix用を作成
  dev->>hotfix_wt: 緊急修正を実施
  dev->>hotfix_wt: コミット＆プッシュ
  Note over dev: 修正完了
  dev->>main_wt: 元の開発作業に戻る
  dev->>dev: hotfix worktree を削除

この図のように、worktree を使えば、開発中のブランチはそのままに、別ディレクトリで緊急対応ができます。

ステップ 1：現在の状態確認

まず、現在の worktree 状態を確認します。

bashCopy codegit worktree list

出力例：

bashCopy code/Users/username/myapp  1a2b3c4 [feature/user-profile]

現在は 1 つの worktree だけが存在している状態です。

ステップ 2：hotfix 用の worktree を作成

緊急バグ修正用に、main ブランチから新しいブランチを作成します。

bashCopy code# main ブランチから hotfix ブランチを作成し、worktree に追加
git worktree add -b hotfix/critical-bug ../myapp-hotfix main

このコマンドにより、以下のことが行われます。

• main ブランチを基点に hotfix​/​critical-bug ブランチを作成
• ..​/​myapp-hotfix ディレクトリに新しい worktree を展開
• 自動的に新しいブランチにチェックアウト

ステップ 3：hotfix ディレクトリで修正作業

新しく作成された worktree ディレクトリに移動して、バグ修正を行います。

bashCopy codecd ../myapp-hotfix

bashCopy code# バグ修正のコードを編集
# 例：src/utils/validation.ts を修正

修正が完了したら、コミットします。

bashCopy codegit add .
git commit -m "fix: critical validation bug in user input"

bashCopy code# リモートリポジトリにプッシュ
git push origin hotfix/critical-bug

ステップ 4：元の開発作業に戻る

緊急修正が完了したら、元の開発ディレクトリに戻るだけで、すぐに作業を再開できます。

bashCopy codecd ../myapp

このとき、feature​/​user-profile ブランチの作業状態はそのまま保持されています。エディタで開いていたファイルも、再度開き直す必要はありません。

ステップ 5：hotfix worktree の削除

緊急修正がマージされ、不要になった worktree を削除します。

bashCopy code# hotfix worktree を削除
git worktree remove ../myapp-hotfix

あるいは、手動でディレクトリを削除してからクリーンアップすることもできます。

bashCopy coderm -rf ../myapp-hotfix
git worktree prune

シナリオ 2：複数の Pull Request を同時にレビュー

複数の PR をローカルで動作確認したい場合も、worktree が便利です。

bashCopy code# PR #123 のブランチを worktree として追加
git worktree add ../review-pr-123 feature/new-api

bashCopy code# PR #124 のブランチを worktree として追加
git worktree add ../review-pr-124 feature/ui-update

それぞれのディレクトリで yarn install と yarn dev を実行すれば、異なるポートで同時に起動して比較できます。

以下の表で、複数 PR レビューの手順を整理します。

#	手順	コマンド例
1	PR のブランチを worktree として追加	git worktree add ..​/​review-pr-123 feature​/​new-api
2	worktree ディレクトリに移動	cd ..​/​review-pr-123
3	依存関係をインストール	yarn install
4	開発サーバーを起動（異なるポート）	PORT=3001 yarn dev
5	ブラウザで動作確認	http:​/​​/​localhost:3001 を開く
6	レビュー完了後、worktree を削除	git worktree remove ..​/​review-pr-123

シナリオ 3：TypeScript プロジェクトでの並行ビルド

TypeScript や Next.js のプロジェクトでは、ビルド時間が長くなることがあります。worktree を使えば、各ブランチで個別にビルド成果物を保持できます。

bashCopy code# feature ブランチの worktree
cd ~/project-main
yarn build  # 5分かかったとする

bashCopy code# 別の worktree で hotfix を作成
git worktree add ../project-hotfix hotfix/urgent
cd ../project-hotfix
yarn install
yarn build  # この worktree 専用のビルド

元のディレクトリに戻っても、ビルド成果物は保持されているため、再ビルドの必要はありません。

よくある使い方のパターン

以下の表で、実務でよく使われる worktree のパターンをまとめます。

#	パターン	コマンド例	用途
1	緊急修正	git worktree add -b hotfix​/​bug ..​/​hotfix main	開発中に緊急対応が必要な場合
2	PR レビュー	git worktree add ..​/​review feature​/​pr-branch	複数 PR を同時に確認
3	長期ブランチ	git worktree add ..​/​v2-development v2	メジャーバージョン開発など
4	実験的開発	git worktree add -b experiment​/​new-arch ..​/​exp	リスクの高い試行錯誤
5	リリース準備	git worktree add ..​/​release release​/​v1.5	本番デプロイ準備と並行開発

まとめ

Git worktree は、複数のブランチを同時並行で開発するための強力な機能です。従来の git checkout による切り替え方式と比べて、以下のような利点があります。

• 作業状態の維持: 各ブランチの作業内容をそのまま保持できます
• 時間の節約: ビルドや依存関係のインストールを各 worktree で独立して管理できます
• 思考の中断を防ぐ: エディタの状態を保ったまま、別のタスクに切り替えられます
• 並行作業の効率化: 複数のタスクをスムーズに切り替えながら進められます

基本的なコマンドは以下の 3 つです。

• git worktree add <path> <branch>: 新しい worktree を作成
• git worktree list: 現在の worktree 一覧を表示
• git worktree remove <path>: worktree を削除

緊急対応や PR レビュー、長期ブランチの並行開発など、さまざまなシーンで Git worktree を活用することで、開発効率を大きく向上させることができます。ぜひ日常の開発フローに取り入れてみてください。

関連リンク

• Git 公式ドキュメント - git-worktree
• Git worktree の使い方 - Atlassian Git Tutorial
• Pro Git Book - Git Tools