git worktreeを活用してブランチ切り替えのストレスから解放されよう

こんにちは！株式会社アップルワールドの riku です！
今日は、知っておくと開発効率が大きく上がる git worktreeの活用術について紹介します。

※この記事はアップルワールド Advent Calendar 2025の2日目の記事です。

複数ブランチを行き来するのは大変

複数ブランチを行き来しながら作業する場面は少なくありません。しかし、そのたびに stash したり、別フォルダに clone を作ったりするのは非効率で、ミスの温床にもなります。

そこで役立つのが git worktree です。

git worktreeを使うと、1つのリポジトリから複数の作業ディレクトリを並列に扱えます。
各ワークツリーはリポジトリの履歴・オブジェクトを共有するため、cloneを複数つくるより圧倒的に軽量です。

これにより、

• 緊急バグ修正
• PR レビュー
• 複数機能の同時開発

といった作業を安全かつ高速に切り替えられるようになります。
近年では、AIエージェントによる並列開発ワークフローとの相性が良いことから再注目されています。

git worktreeは Git 2.5（2015 年）で登場した機能です。
https://github.blog/open-source/git/git-2-5-including-multiple-worktrees-and-triangular-workflows/

主なユースケース

• 機能開発を複数並行したい（AIとの相性抜群）
• 別ブランチで緊急修正が必要になったとき、今の作業を中断したくない
• レビュー対象のPRをローカルで動作確認したいが、作業中ブランチを壊したくない

注意点

• 同じブランチを複数の worktree でチェックアウトすることはできない
• 並列開発は便利な反面、コンテキストスイッチが増えすぎると普通にしんどい

PR レビューが圧倒的にラクになる

PR をローカルで確認するとき、従来は

1. 今の作業を stash
2. レビューブランチに checkout
3. 動作確認
4. 作業ブランチに戻り、stash pop
5. たまにコンフリクト…

と、地味に時間を奪われがちです。

しかし git worktreeを使えば、

git worktree add ../review-123 feature/add-awesome-ui

この1行で、レビュー用の別ディレクトリを作成できます。
現在の作業ディレクトリには一切触れないため、

• stash が不要
• 作業環境を壊す心配がない
• PR ごとに独立した環境を準備できる

というメリットがあります。

特に、

• 手元で動かしてレビューしたい
• 複数 PR を並行で見たい

といった場面で威力を発揮します。
一度慣れると、checkoutベースのレビューには戻れません。

緊急対応が “ゼロ秒” で開始できる

本番障害が起きたときに辛いのは「今の作業が中途半端」な状態です。stash を挟んだり差分を壊したりする事故は、焦るほど起きやすくなります。

ここでも git worktreeが有効です。

git worktree add ../hotfix-2025 hotfix/urgent-bug

これで障害対応用の環境が即座に用意できます。
元の作業ディレクトリは一切触らないため、

• すぐ修正に着手できる
• 作業中ブランチを壊さない
• 緊急時の Git 操作ミスを防げる

と、技術的にも心理的にも大きな安心感があります。
複数プロジェクトが並行する組織や、対応速度がビジネスに直結する現場では特に効果的です。

“ブランチは切り替えるもの” から “並列に存在させるもの” へ

git worktreeを使うと、ブランチの考え方が根本的に変わります。

• PR レビュー
• 障害対応
• 動作検証
• AI によるコード生成
• 通常開発

これらを互いに干渉しない複数の作業空間として扱えます。
ストレスとコンテキストスイッチが劇的に減り、「今の作業を壊したくない」という負担から解放されます。

結果として、

• 作業スピードの向上
• コードの安全性・安定性の向上

にもつながります。

git worktreeの基本操作

実際の操作方法を紹介します。

既存ブランチを指定して worktree 追加

# feature/add-awesome-uiブランチを指定してreview-123worktreeを追加
git worktree add ../review-123 feature/add-awesome-ui

ポイント：

• 1 つ目に「作りたいディレクトリ」、2 つ目に「ブランチ名」を指定
• ブランチが存在しない場合は新規作成も可能

main から新規ブランチを切って worktree 作成

# mainからfeature/xyzブランチを作成。worktreeはfeature-xyz
git worktree add ../feature-xyz -b feature/xyz main

作成済み worktree を確認する

git worktree list

どのディレクトリがどのブランチを使っているか一目で分かります。

worktree を削除する

git worktree remove ../review-123

ディレクトリを直接削除せず、このコマンドで削除するのが安全です。

ディレクトリ構成の例

~/projects/
  my-app/              # メイン作業
  my-app-review-123/   # PR #123 のレビュー
  my-app-hotfix-2025/  # ホットフィックス
  my-app-exp-ai/       # AI 実験用

用途をディレクトリ名に含めておくと、どこで何をしているか一目で分かります。

git worktreeを運用するときのポイント

1. ディレクトリ命名ルールを決める
   • review: repo-name-review-<PR番号>
   • hotfix: repo-name-hotfix-<YYYYMMDD>
   • 実験: repo-name-exp-<用途>

バラバラだと混乱しやすいため、用途が分かる命名が必須です。

2. 「終わったら消す」習慣をつける
   • PR レビュー完了時
   • 障害対応ブランチのマージ時
   • 実験終了時

など、削除のタイミングをルール化するとローカルが散らかりません。

3. 開発ルールやドキュメントに組み込む

例：

• 「PR レビューは worktree での検証を推奨」
• 「緊急対応は別 worktree で実施する」

これだけでチーム全体の開発体験が改善します。

よくあるハマりどころ

git worktreeは素晴らしい機能ですが、万能ではありません。
細かいですが、ハマりポイントをお伝えします。

同じブランチは複数worktreeで使えない

仕様上、1つのブランチを複数worktreeでcheckoutすることはできません。
必要ならブランチを切る・運用を見直すなどの対処が必要です。

worktree を放置して増えがち

使い終わったら git worktree remove で消す習慣をつけましょう。
※これはcheckout運用でも同じですね

エディタやツールの設定が worktree に依存する場合がある

VS Codeの設定や.envファイルなどがディレクトリ依存の場合、worktreeごとにズレが出ることがあります。
必要なら.gitignoreやテンプレートファイルを整備しましょう。

まとめ

git worktreeを導入すると、

• PR レビューのストレスが激減
• 緊急障害でも stash / checkout の負担ゼロ
• ブランチを “切り替える” から “並行させる” 開発体験へ移行

といったメリットがあります。

特に、

• 複数タスクを並行して進める
• PR をローカルで動作確認する文化がある
  -　障害対応がシビア
• AI エージェントと並列開発したい

といった環境では、開発体験が大幅に向上します。

---

git worktree自体はとてもシンプルな仕組みですが、使い方次第で開発体験を大きく変えてくれます。
まだ使ったことがない方は、まずは1つPRレビュー用のworktreeを作るところから試してみてください。

明日の AppleWorld Advent Calendar もお楽しみに！
それでは、良い worktree ライフを 👋