はじめに
開発中に 「別ブランチの緊急修正を入れたい」「リリースブランチを長期間保持したい」――そんなときに git checkout で行ったり来たりすると作業ツリーが汚れ、衝突の温床になります。
Git 2.5（2015 年）で正式公開された git worktree を使えば、1 つのリポジトリから複数の“作業ツリー（Worktree）”を生やし、各ツリーで別々のブランチを同時に操作できます。
この記事では最新版 Git 2.45 時点での機能・落とし穴・実戦的なワークフローまで徹底解説します。
1. なぜ git worktree なのか
1‑1. 追加 clone と worktree の違い
| 方法 | ディスク容量 | フェッチ回数 | オブジェクト整合性 |
|---|---|---|---|
| 追加 clone | 100 % × clone 数 | clone ごと | 分断される |
| worktree | 共有分のみ 1 コピー | 1 度の git fetch で全ツリー反映 |
常に一貫 |
1‑2. 典型ユースケース
- 緊急修正：現在の開発作業を汚さずに main から派生したワークツリーで修正 → マージ
-
リリース保守：
release/X.Y用ワークツリーを常設し、パッチ適用を迅速化 - コードレビュー／CI 再現：Pull Request の HEAD をローカルでビルド・デバッグ
-
巨大 mono‑repo：ワークツリーごとに
sparse-checkoutを変え、容量とビルド時間を削減
2. 基本文法と主要サブコマンド
| コマンド | 目的 | 代表例 |
|---|---|---|
git worktree add [-b <新ブランチ>] <path> [<commit-ish>] |
作業ツリーを追加 | git worktree add -b hotfix ../hotfix origin/main |
git worktree list [--porcelain] |
既存ツリーの一覧 | git worktree list --porcelain |
git worktree remove [--force] <path> |
作業ツリーを削除 | git worktree remove ../hotfix |
git worktree prune |
存在しないツリー情報の掃除 | git worktree prune |
git worktree lock [--reason <msg>] / unlock
|
別メディア上ツリーの保護 | git worktree lock ../usb --reason "出張用" |
git worktree move <新パス> |
物理フォルダを移動 (Git 2.17+) | git worktree move ../v2 ../archive/v2 |
git worktree repair |
.git/worktrees と実フォルダのずれを修復 |
git worktree repair |
3. 5 分でわかる実践シナリオ
3‑1. 開発中に緊急 Hotfix が入った
# 1. 機能開発中 (feature/login)
$ git status # まだコミット前の変更あり
# 2. Hotfix 用ワークツリーを作成
$ git worktree add -b hotfix-login ../hotfix-login origin/main
# 3. 作業ディレクトリを切り替え
$ cd ../hotfix-login
$ <修正を加えコミット>
# 4. main へマージし、CI が通ったらリリース
$ git checkout main
$ git merge --no-ff hotfix-login
3‑2. リリースブランチを常駐させる
# リリース 1.x を別フォルダに常設しビルド検証に使う
git worktree add ../release-1.x origin/release/1.x --lock
4. メカニズムを掘り下げる
4‑1. .git/worktrees ディレクトリ構造
4‑2. 共有／非共有ファイル
-
共有: Git オブジェクト (
objects/,refs/ほか) -
個別:
HEAD,index,config.worktreeなど “作業ツリー固有” ファイル -
config.worktree(Git 2.26+) により sparse‑checkout やフック設定をツリー単位で分離可能
4‑3. GC と自動クリーンアップ
- 既定値
gc.worktreePruneExpire = 3.months - 取り外し可能メディアに置く場合は
git worktree lockまたは期間延長推奨
5. よくある落とし穴と対策
| 症状 | 原因 | 解決策 |
|---|---|---|
| 同じブランチを別ツリーにチェックアウト不可 | ブランチは同時に 1 ツリーのみ |
--detach でコミットハッシュ checkout ／一時ブランチ作成 |
worktree is not sparse 警告 |
sparse‑checkout 設定ずれ |
git sparse-checkout disable → 再設定 |
| ワークツリーのフォルダを手動で移動 | パス不一致 | git worktree repair |
| 削除時に「untracked files あり」 | 作業ツリーが汚れている |
git worktree remove --force または .gitignore 更新 |
6. チームで運用するためのベストプラクティス
-
ディレクトリ構造統一
例：../worktrees/{feature|release|hotfix}-<name>で種別を先頭に -
定期的な
git worktree prune
CI ジョブや pre‑push フックで自動実行 -
エイリアス活用
[alias] wt = worktree wtl = worktree list wta = worktree add -b -
IDE / ツール互換性チェック
路径解決がリポジトリルート基準かを確認 -
大規模リポでの sparse‑checkout 併用
ワークツリーごとに対象ディレクトリだけ展開し、ビルド時間を短縮
7. まとめ
-
git worktreeは clone を増やさず“枝分かれした作業ツリー”を即席で作成。 -
add / list / remove / prune / lock / move / repairを押さえれば日常利用は OK。 - メタ情報は
.git/worktreesに集約され、git gcとworktree pruneが掃除役。 - 緊急 Hotfix・長期リリース保守・CI デバッグ・mono‑repo 部分 checkout まで応用範囲広し。
- チームで命名規則・自動 prune・IDE 連携 を合意し、並行開発をストレスなく回そう！
これで clone 地獄 から卒業。
git worktreeを武器に、複数ブランチを 並行・安全・高速 に扱う新しい開発スタイルを始めましょう。