Git Worktree と Git Branch の開発の違いとは？どんな状況で Git Worktree での開発が適しているのか？

新機能の開発を半分進めたところで、上司が突然急ぎのバグ修正を求めてきたら、どうしますか？

ほとんどの人は git stash を使って書きかけのコードを引き出しに押し込み、ブランチを切り替えてバグを修正するでしょう。

しかし、変更内容に大規模な環境設定が含まれていたり、ブランチの切り替えによって node_modules や ビルド成果物 (Build Artifacts) が相互に汚染されるような場合は、キーボードを叩き割りたくなるかもしれません。

そんなときこそ、Git Worktree が救世主となります！

Git Worktree とは？

Git の動きは「家のリフォーム」によく似ています。

従来の git branch では、ブランチを切り替えると部屋の家具が一瞬にして目の前から消え、別のタスクに合った配置に自動的に変わります。

スペースの節約にはなりますが、デメリットは**「環境汚染」**です。洗っていない食器を棚に片付けないと切り替えられませんし、切り替えた後も、前回の作業の油臭さが空気中に残っているかもしれません。

一方、Git Worktree は、隣の空き地に全く同じ家を建てるようなものです。

簡単に言えば、Git の根底にある原理は次のようになります：

「1つの魂 (.git データベース) と複数の肉体 (作業ディレクトリ)」。

「機能開発の支店」と「緊急修理の支店」を同時に持つことができます。左手でウィンドウAの AI ロジックを書きながら、右手でウィンドウBのバグを修正する。両者は互いに干渉しません。これこそが真の並行開発です。

開発中にフロー状態を維持するには、ディレクトリ構造と環境設定が鍵となります。

初めて Worktree を使う人の多くは、元のプロジェクトフォルダ内に新しいディレクトリを作ってしまいます。絶対にやってはいけません！Git が無限ループの混乱に陥ります。Git Worktree の正しい作り方は以下の通りです：

本店 (main) とタスク支店 (feature) は並行して配置する。

# 本店で Worktree の作成を実行しますが、Worktree のディレクトリは元のプロジェクトディレクトリの外に配置します
git worktree add ../my-app-feat-ai dev-branch

ディレクトリ構造は次のようになるはずです：

- my-project/       # 大きなパッケージ
  - main-repo/      # 安定した本店
  - feat-ai-search/ # 建設中の新しい支店

プロジェクトディレクトリが別々なので、.env 設定ファイルも分けることができます。

main では元の開発データベースを維持しながら、feat-ai-search ではテスト用データベースに接続することができます。こうすることで、ウィンドウを切り替える際に接続情報を変更する必要すらありません。

Worktree ディレクトリに入った後、その特定の Worktree ディレクトリの環境変数をそのまま使って開発を進めることができます。環境の切り替えや再構築は一切不要です。**「足を踏み入れた瞬間に仕事が始められる」**という感覚は、本当に素晴らしいものです。

Worktree での開発を終えた後のワークフローは、従来のブランチと全く同じで、最後に「解体」というアクションが1つ追加されるだけです。

ワークフローステップ	説明
1. 支店でのコミット (Commit & Push)	承認するためには、物理的に支店に行く必要があります。
2. 本店の検査 (Merge)	`main` に戻ってマージするか、直接 Pull Request (PR) を開くことができます。
3. エレガントな解体 (Remove)	タスクが完了したら、フォルダを直接削除しないでください。Git コマンドを使って解体します：`git worktree remove ../feat-ai-search`

ドカーン！ 仮設の Worktree 小屋は撤去され、ディスクスペースは回収され、あなたの本店はピカピカのままです。

Worktree は非常に便利ですが、注意すべき落とし穴がいくつかあります：

項目	説明
無闇に本店を移動しない	Worktree は絶対パスを記録しているからです。本店のディレクトリ名を変更すると、Worktree 支店は「魂」を見つけられずに死んでしまいます。
二重ブランチの禁止	同じブランチを2つの Worktree で同時にチェックアウトすることはできません。
お掃除ロボット `prune`	誤って `rm -rf` でフォルダを削除してしまった場合は、忘れずに `git worktree prune` を実行して `.git` に残っている記録を消去してください。

シナリオが異なれば、適した開発手法も異なります。どちらかが代わりになるという問題ではなく、どちらが適しているかという問題です。

シナリオ	説明
日常の小さな変更	引き続き `branch` を使ってください。軽快で高速です。
大規模なタスク	例えば、大規模なリファクタリング、複数の環境変数にまたがる調整、AIとの長期的な連携が必要なタスクなどには、Worktree を立ち上げるのが間違いなく最善の選択です。

Git Worktree は単なるコマンドではなく、私たちの開発のフロー状態を維持するための強力なツールです。次回、面倒で大規模なタスクに直面したときは、独立した 「Git Worktree 支店」 を開いて、これまでにないスムーズな開発プロセスを体験してみてください！