🐈

世界一わかりやすくGit worktreeを解説！AI駆動開発でも活用できる並列開発の方法

に公開
Git
開発環境
ブランチ
AI駆動開発
worktree
tech

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

「このブランチで作業中なのに、急に別のブランチを確認しないといけなくなった...」

「でも今の作業は中途半端だし、コミットやスタッシュで退避するのもなぁ...」

こんな経験はありませんか?

Gitでの開発では、複数のタスクを並行して進める場面がよくあります。

そんなとき便利なのが Git worktree という機能です。

今回は、Gitの基礎を押さえながら、worktreeの使い方を初心者の方にもわかりやすく解説します。

また、Anthropic社もGit worktreeの活用を推奨しており、AI駆動開発でも活用できますのでぜひ覚えていってください！

https://docs.claude.com/ja/docs/claude-code/common-workflows#gitワークツリーで並列claude-codeセッションを実行する

著者について

とまだ

  • Claude Code・Cursor・Codex などAI駆動開発の実践者
  • 本業はフリーランスエンジニア、ならびに法人向けAI駆動開発の導入コンサルタント
  • AI駆動開発を学ぶ方が集まる Vibe Coding Studio コミュニティを運営
  • UdemyでAI駆動開発を学べる複数のベストセラー講座を展開
  • 東京AI祭プレイベントに登壇
  • プログラミングスクール講師として100名以上に指導経験

SNS

忙しい人のために要約

  • worktreeは「同じリポジトリで複数の作業フォルダを持てる」機能
  • ブランチ切り替え不要で、複数タスクを同時並行できる
  • 作業の流れ: worktree作成 → 作業 → コミット → worktree削除
  • 新規ブランチで始めるなら git worktree add -b が便利
  • 作業が終わったらフォルダを削除するだけでOK
  • AI駆動開発でも活用できる並列開発の方法

まずはGitの基本をおさらい

まず、worktreeを理解する前に、Gitの基本的な仕組みを確認しておきましょう。

既にご存じの方は読み飛ばしていただいて構いません。

リポジトリとは

リポジトリは、プロジェクトのファイルと履歴を管理する場所です。

簡単に言うと、図書館の本棚のようなもので、コードとその変更履歴を保管していますね。

具体的には、パソコンの中にあるプロジェクトフォルダが、そのままリポジトリになるわけです。

# 例: my-projectフォルダがリポジトリ
my-project/
  ├── .git/          # Gitの管理データ(見えないフォルダ)
  ├── src/           # ソースコード
  └── README.md      # プロジェクト説明

.git フォルダの中に、すべての履歴情報が保存されているのをご存じでしょうか。

ブランチとは

では次に、ブランチは「開発の流れ」を管理する仕組みです。

本の章立てのように、機能ごとに分けて開発を進められます。

# mainブランチ(本編)
main ──●──●──●──●
       |
       └──●──● # feature/new-apiブランチ(新APIの開発)

つまり、新機能を作るときは、mainブランチから分岐して作業するわけですね。

作業ディレクトリとは

また、作業ディレクトリは、今実際にファイルを編集している場所のことです。

例えば、図書館から本を借りて家で読んでいる状態に似ています。

通常、1つのリポジトリには1つの作業ディレクトリしかありません。

# 普通のGitの使い方
cd my-project           # 作業ディレクトリに移動
git checkout feature-a  # ブランチを切り替え
# ↑ ファイルの内容がfeature-aブランチの状態に変わる

そのため、ブランチを切り替えると、フォルダ内のファイルがそのブランチの内容に入れ替わりますね。

worktreeとは何か?

ここまで、Gitの基本を見てきました。

では次に、worktreeとは何かを見ていきましょう。

複数の作業場所を持てる仕組み

Git worktreeは、同じリポジトリで複数の作業フォルダを作れる機能なんです。

簡単に言うと、1つのプロジェクトを複数の場所で同時に開けるようになります。

通常は1つのフォルダで複数のブランチを切り替えて使います。

しかしworktreeを使うと、複数のフォルダを同時に使えるわけですね。

# worktreeを使った場合
my-project/              # メインの作業フォルダ(mainブランチ)
my-project-feature-a/    # 別の作業フォルダ(feature-aブランチ)
my-project-feature-b/    # さらに別の作業フォルダ(feature-bブランチ)

それぞれのフォルダが独立しています。

そのため、ブランチを切り替えずに複数の作業を同時進行できるわけですね。

日常の例で理解する

では、日常の例で理解してみましょう。

本を読む場面で考えてみます。

まず、通常のブランチ切り替えは、1つの机で複数の本を読み替える感じです。

  • 小説を読んでいたが、急に参考書を開く必要が出た
  • 小説にしおりを挟んで閉じる(変更を退避)
  • 参考書を開いて確認する
  • また小説に戻る

一方で、worktreeは、複数の机を用意して同時に開いておく感じです。

  • 机A: 小説を開きっぱなし
  • 机B: 参考書を開きっぱなし
  • 机C: 雑誌を開きっぱなし

それぞれ独立した作業場所を持つことができるため、どの机でも好きなときに作業できます。

通常のGit操作との違い

通常のGit操作では、ブランチを切り替えるたびに以下の問題が起きます。

# feature-aで作業中
git checkout feature-a
vim src/app.js  # ファイルを編集中...

# 急にmainブランチを確認したい
git checkout main
# → エラー! 編集中のファイルがあるため切り替えられない

# 仕方なくコミットするか...
git add .
git commit -m "WIP: 作業途中"
# → 中途半端なコミットが履歴に残る

# または退避するか...
git stash
# → 後で戻すのが面倒

編集中のファイルがあるとブランチを切り替えられず、コミットやstashで退避する必要があるわけですね。

しかし、worktreeを使えば、この問題がなくなります。

# メインフォルダでfeature-aを作業中
cd my-project
vim src/app.js  # 編集中...

# 別フォルダでmainブランチを確認
cd ../my-project-main
# → feature-aの編集内容はそのまま残っている!

ブランチとworktreeの関係

ここまで、worktreeの基本的な概念を説明しました。

しかし、ブランチとworktreeの関係がまだ曖昧かもしれません。

次は、この2つの関係を整理しましょう。

ブランチは「履歴の枝分かれ」

まず、ブランチは、コミット履歴の枝分かれを表します。

つまり、開発の歴史が木の枝のように分岐していくイメージですね。

# ブランチの例
main          ●──●──●──●
               └──●──●  feature-a
               └──●──●  feature-b

そのため、ブランチは .git フォルダの中にある情報で、どのフォルダからでもアクセスできますね。

worktreeは「作業用のフォルダ」

一方で、worktreeは、特定のブランチをチェックアウトした状態のフォルダです。

言い換えると、それぞれのブランチを別々のフォルダで開いている状態なんですね。

my-project/              # mainブランチの内容
my-project-feature-a/    # feature-aブランチの内容

このように、それぞれのフォルダには、そのブランチのファイルが配置されていますね。

両者の関係を図で理解する

では、両者の関係を図で理解してみましょう。

.git/(履歴データ)
  ├── mainブランチ        ← my-project/で作業中
  ├── feature-aブランチ   ← my-project-feature-a/で作業中
  └── feature-bブランチ   ← my-project-feature-b/で作業中

このように、.git フォルダは1つだけで、複数のworktreeがそこから情報を読み込むわけですね。

重要な制約

また、重要な制約として、1つのブランチは1つのworktreeでしか使えません。

# これはできない
git worktree add ../project-main main
git worktree add ../project-main-2 main  # エラー!
# → mainブランチは既に使用中

これは、同じブランチを複数の場所で編集すると混乱するのを防ぐためなんですね。

worktreeの基本的な使い方

ここまで、ブランチとworktreeの関係を説明しました。

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

準備: 基本的なGitリポジトリ

まず、練習用のリポジトリを用意します。

# 新しいフォルダを作成
mkdir my-project
cd my-project

# Gitリポジトリとして初期化
git init

# 最初のファイルを作成
echo "# My Project" > README.md
git add README.md
git commit -m "初回コミット"

これで、mainブランチを持つリポジトリができましたね。

パターン1: 新規ブランチでworktreeを作る

では、新しい機能を開発するときは、この方法が一番簡単ですね。

# 新しいブランチとworktreeを同時に作成
git worktree add -b feature/new-ui ../my-project-new-ui

# これで以下が同時に行われる:
# 1. feature/new-uiブランチが作成される
# 2. ../my-project-new-uiフォルダが作成される
# 3. そのフォルダでfeature/new-uiがチェックアウトされる

つまり、-b オプションで新しいブランチ名を指定すると、ブランチ作成とフォルダ作成が1つのコマンドで完了します。

とても簡単ですね。

パターン2: 既存ブランチでworktreeを作る

また、既にあるブランチを使う場合は、ブランチ名だけを指定します。

# 既存のブランチでworktreeを作成
git worktree add ../my-project-hotfix hotfix/bug-123

# hotfix/bug-123ブランチが既に存在する必要がある

作成されたworktreeを確認する

では次に、どのworktreeが存在するか確認できますね。

git worktree list

# 出力例:
# /Users/tomada/my-project              abc1234 [main]
# /Users/tomada/my-project-new-ui       def5678 [feature/new-ui]
# /Users/tomada/my-project-hotfix       ghi9012 [hotfix/bug-123]

worktreeで実際に作業する

それでは、作成したworktreeで普通に開発してみましょう。

例えば、新しいUIファイルを作成してコミットしてみます。

# worktreeフォルダに移動
cd ../my-project-new-ui

# ファイルを編集
echo "新しいUI" > new-ui.html

# 通常通りコミット
git add new-ui.html
git commit -m "新しいUIを追加"

# リモートにプッシュ
git push origin feature/new-ui

このように、Git操作は通常のリポジトリと全く同じなので安心してください。

worktreeを削除する

では次に、作業が終わったら、worktreeを削除しましょう。

# メインのリポジトリに戻る
cd my-project

# worktreeを削除
git worktree remove ../my-project-new-ui

また、フォルダを直接削除した場合は、参照を整理しますね。

# フォルダを直接削除した場合
rm -rf ../my-project-new-ui

# Gitに削除されたworktreeの情報を整理させる
git worktree prune

ブランチはどうなる?

では、worktreeを削除しても、ブランチ自体は残りますね。

# ブランチの一覧を確認
git branch
# → feature/new-uiブランチはまだ存在する

# ブランチも削除したい場合
git branch -d feature/new-ui  # マージ済みなら -d
git branch -D feature/new-ui  # 強制削除なら -D

worktreeの作成順序について

ここまで、worktreeの基本的な作成・削除方法を見てきました。

しかし、初心者の方がよく迷うのが、「ブランチとworktreeをどちらから作るべきか」という点です。

次は、この順序について整理しましょう。

推奨方法1: worktree作成時にブランチも作る

まず、これが一番わかりやすくて、初めて使う方におすすめですね。

# 1つのコマンドで完了
git worktree add -b feature/login ../my-project-login

# やっていること:
# ① feature/loginブランチを新規作成
# ② ../my-project-loginフォルダを作成
# ③ feature/loginブランチをチェックアウト

推奨方法2: 既存ブランチを指定する

また、ブランチが既にある場合は、この方法を使いますね。

# 先にブランチを確認
git branch
# → feature/loginブランチが存在することを確認

# そのブランチでworktreeを作成
git worktree add ../my-project-login feature/login

避けるべき方法: ブランチを指定しない

一方で、ブランチを指定せずにworktreeを作るのは混乱の元です。

# これは避けるべき
git worktree add ../my-project-temp
# → HEADの状態がコピーされるだけ
# → どのブランチで作業しているか分かりにくい

そのため、ブランチ名を指定するのがおすすめです。

作業が終わったらどうするか

ここまで、worktreeを作成する方法を説明しました。

では次に、作業が終わったときの片付け方を見ていきましょう。

worktreeでの作業が完了したら、以下の手順で片付けますね。

手順1: 変更をコミット・プッシュ

worktreeでの作業を保存します。

cd my-project-feature

# 変更をコミット
git add .
git commit -m "機能を完成"

# リモートにプッシュ
git push origin feature/new-feature

手順2: worktreeを削除

では次に、メインのリポジトリに戻って削除しましょう。

# メインリポジトリに移動
cd my-project

# worktreeを削除
git worktree remove ../my-project-feature

このようにフォルダが削除され、worktreeの登録も解除されますね。

手順3: ブランチの処理

最後に、ブランチをどうするか決めましょう。

# マージ済みなら削除
git branch -d feature/new-feature

# まだ使う予定があるなら残す
# (何もしなくてOK)

トラブル: フォルダを先に削除してしまった

また、フォルダを直接削除してもGitの記録は残っていますね。

# フォルダを誤って削除
rm -rf ../my-project-feature

# Gitの記録を整理
git worktree prune

# 確認
git worktree list
# → 削除したworktreeが一覧から消える

このように、prune コマンドで整理すれば問題ありませんね。

worktreeが便利な場面

ここまで、worktreeの使い方と片付け方を見てきました。

では次に、実際の開発でどんなときにworktreeが便利か、具体的な場面を見ていきましょう。

場面1: 機能開発中に緊急バグ修正

例えば、新機能を開発中に、本番環境でバグが見つかった場合です。

# 新機能開発中
cd my-project
# feature/new-dashboardブランチで作業中

# 緊急バグ修正用のworktreeを作成
git worktree add -b hotfix/critical-bug ../my-project-hotfix

# 緊急対応
cd ../my-project-hotfix
# バグを修正
git add .
git commit -m "緊急バグを修正"
git push origin hotfix/critical-bug

# 元の作業に戻る
cd my-project
# → 新機能開発の続きができる

このように、作業中のファイルをコミットしたり退避したりする必要がありませんね。

場面2: プルリクエストのレビュー

また、チームメンバーのコードをレビューする場合も便利です。

# 自分の作業フォルダ
cd my-project
# 自分のブランチで作業中

# レビュー用のworktreeを作成
git fetch origin
git worktree add ../my-project-review origin/teammate-feature

# レビュー
cd ../my-project-review
# コードを確認、動作テスト

# レビューが終わったら削除
cd my-project
git worktree remove ../my-project-review

このように、自分の作業を中断せずにレビューできるわけですね。

場面3: 複数の機能を並行開発

さらに、複数のタスクを同時に進める場合にも役立ちます。

# フロントエンド機能
git worktree add -b feature/frontend ../my-project-frontend

# バックエンドAPI
git worktree add -b feature/api ../my-project-api

# データベース設計
git worktree add -b feature/database ../my-project-db

# それぞれのフォルダで独立して作業できる

このように、ブランチ切り替えの手間がなくなり、効率的に開発できますね。

場面4: 異なるバージョンの比較

また、例えば新旧のコードを比較したい場合にも使えます。

# 現在のバージョン
cd my-project  # mainブランチ

# 過去のバージョンをworktreeで開く
git worktree add ../my-project-v1 v1.0.0

# 2つのフォルダを開いて比較
code my-project my-project-v1

このように、VSCodeなどで2つのフォルダを開いて比較できるわけですね。

よくある質問と答え

ここまで、worktreeの使い方と便利な場面を見てきました。

最後に、よくある質問をまとめておきますね。

Q1: 同じブランチで複数のworktreeを作れる?

A: いいえ、作れません。

1つのブランチは1つのworktreeでしか使えないという制限がありますね。

# これは エラーになる
git worktree add ../project-main main
git worktree add ../project-main-2 main
# error: 'main' is already checked out at '/path/to/project-main'

この制限は、同じブランチを複数の場所で編集して混乱するのを防ぐためなんです。

Q2: worktree間でファイルは共有される?

A: いいえ、各worktreeは独立しています。

ただし、Gitリポジトリ本体(.gitフォルダ)は共有されます。

# worktree-a(feature-aブランチ)で変更
cd my-project-a
echo "変更" > file.txt
git add file.txt
git commit -m "feature-aの変更"

# worktree-b(feature-bブランチ)では見えない
cd ../my-project-b
cat file.txt  # → 変更前の内容(feature-bブランチの状態)

# 別ブランチの変更を取得するには
git fetch  # まず最新情報を取得
git merge origin/feature-a  # feature-aブランチの変更をマージ
# または
git checkout feature-a  # feature-aブランチに切り替え
cat file.txt  # → 変更後の内容が見える

コミットした内容は.gitフォルダに保存されるため、他のworktreeからもgit fetchやgit merge、git checkoutで取得できます。

Q3: worktreeを作りすぎると重くなる?

A: worktreeは.gitフォルダを共有するため、比較的軽量です。
（完全にコピーするわけではない、というぐらいの理解で良いです）

ただし、各worktreeには作業ファイルが配置されるため、ディスク容量は消費します。

# .gitフォルダは共有(1つだけ)
# 各worktreeには作業ファイルのみ
ls -lh
# my-project/.git/      (履歴データ、共有)
# my-project/           (作業ファイル)
# my-project-feature1/  (作業ファイル)
# my-project-feature2/  (作業ファイル)
# → 合計1.1GB

完全なクローンを3つ作るより軽量ですが、使わなくなったworktreeはこまめに削除することをおすすめします。

Q4: worktreeとブランチ、どっちを先に作る?

A: git worktree add -b で同時に作るのが最もシンプルです。

# おすすめ: 同時作成
git worktree add -b feature/new ../project-new

# 別々に作る場合
# ① ブランチを作成
git branch feature/new

# ② worktreeを作成
git worktree add ../project-new feature/new

どちらでも結果は同じですが、同時作成の方が手順が少なくて楽ですね。

もちろん、先にブランチを作ってから worktree を作成する方法もあります。

お好みやチームの運用に合わせて選んでください。

Q5: worktreeを削除したらブランチも消える?

A: いいえ、ブランチは残ります。

# worktreeを削除
git worktree remove ../project-feature

# ブランチは残っている
git branch
# → feature/new-featureがまだ存在

# ブランチも削除したい場合
git branch -d feature/new-feature

このように、worktreeとブランチは独立しているので、別々に管理するわけですね。

まとめ

お疲れさまでした！Git worktreeの基本から実践までをマスターしましたね。

Git worktreeは、複数のブランチを同時に扱える便利な機能なんです。

では、重要なポイントをおさらいしましょう。

  • worktreeは「同じリポジトリで複数の作業フォルダを持てる」機能
  • ブランチは履歴の枝分かれ、worktreeは作業場所
  • 新規ブランチで始めるなら git worktree add -b ブランチ名 フォルダ名
  • 既存ブランチなら git worktree add フォルダ名 ブランチ名
  • 作業が終わったら git worktree remove フォルダ名 で削除
  • ブランチとworktreeは独立して管理される
  • 緊急対応、レビュー作業、並行開発に特に便利

はじめは少し複雑に感じるかもしれませんが、大丈夫です。

一度使い始めると「なんだ、こんなに便利だったんだ!」と気づくはずです。

この知識があれば、もう「作業中だけど別ブランチを確認したい...」という悩みから解放されますね。

複数のタスクを効率的に進めたいとき、ぜひworktreeを試してみてください！

この記事が役に立ったら「いいね」で応援いただきつつ、Xもフォローしていただけると嬉しいです！！！

AI駆動開発を学ぶ同士が集まるDiscordコミュニティを運営しています

Discord無料コミュニティ「Vibe Coding Studio」では、AI駆動開発を学ぶ同士が集まり、最新情報を共有しています。
また、実装例も公開していたり、参加者によるナレッジシェアも活発ですので、興味がある方はぜひご参加ください！

今回の記事の内容について、ご質問や相談があれば、お気軽にDiscordでお声がけください！

https://www.vibecodingstudio.dev/community

参加したら、まずは times を作って日々の学びをシェアしてくれると嬉しいです！！！

Discussion