Git のワークツリーとは何か、そしてなぜ使用するべきなのか？

最近の Git の話題では、ワークツリーという概念が注目されています。これは少し皮肉なことに、2015 年からすでに存在していたものです。 しかし、それでも彼らは素晴らしいものであり、なぜそれを使うのか、ブランチとどう違うのか、そしてなぜ急にこれほど人気があるのかを疑問に思っているかもしれません。 それについて話しましょう！ ブランチとスタッシュによるコンテキストスイッチング ワークツリーのない世界に住んでいて、あるチケットの作業をしていたところ、突然緊急のバグが発生してコンテキストを切り替えなければならなくなったと仮定してみましょう。 まず、作業をスタッシュします： git stash "wip feature login" 次に、メインブランチに切り替えて更新します： git checkout main git pull origin main その後、バグ修正用のブランチを作成します： git checkout -b hotfix-bug そして、すべての問題を修正し、コミットしてブランチをプッシュします： git add . git commit -m "fix broken submit button" git push origin hotfix-bug その後、プルリクエストのマージが終わったら、コンピュータに戻ってメインを取得し、バグ修正ブランチを削除するかもしれません： git checkout main git pull origin main git branch -d hotfix-bug そして、以前作業していた機能に戻ることができます： git checkout feature-login git stash pop ふぅ。どこまで進んだっけ？ 切り替えやファイルの再読み込み、何らかの変更に基づいて node_modules の再インストールなどを行う際の精神的な負荷は非常に大きいです。コンテキストスイッチングの負担は重いです。 さて、これは基本的な例ですが、時には開発者がより複雑な git stash コマンドを実行したり、同じリポジトリの複数のクローンを作成したりして、このような混乱を回避することがあります（私もその一人です）。 それが…ワークツリー登場！ ワークツリーによるコンテキストスイッチング ワークツリーを使えば、ブランチから離れることもなく、stash する必要もありません。元の機能の編集コンテキストもそのまま維持されます。 git worktree add ../hotfix-workspace -b hotfix-bug main これにより、すぐに"hotfix-workspace"という兄弟フォルダが作成され、main ブランチをベースとして、"hotfix-bug"という新しいブランチをチェックアウトします。 これで、そのフォルダを新しいエディタウィンドウで開く（または cd して移動し）バグを修正できます。元のエディタウィンドウは、あなたが離れる前と全く同じ状態のままです。 cd ../hotfix-workspace # ...fix fix fix... git add . git commit -m "fix broken submit button" git push origin hotfix-bug オンラインでプルリクエストをマージするのは以前と同じように行い、マージが完了したら、一時フォルダを単に削除するだけです。 cd ../main-project git worktree remove ../hotfix-workspace これははるかにスムーズです！stash の競合リスクはゼロ、エディタの中断もなく、真に並列して作業できます。 では…なぜ今なのか？ 非常に長い間、ワークツリーは比較的知られていませんでした。多くの開発者はこれについて聞いたことがありませんでした。なぜなら、Git GUI がこれをサポートしていなかった（または準二等公民として扱っていた）か、あるいは単に「機能ブランチを作成→作業→PR 提出→マージ→繰り返し」という既知のパターンに従ってきたからです。 さて、開発者としての私たちの仕事は変化しました。AI の登場により、ソフトウェア開発の歴史においてこれまで以上に並行して作業を行うようになりました。開発者はかつてないほど多くのセッションを並行して実行しており、「コードレビュー文化」が「コード記述文化」を超えて成長しています。 エージェントと人間は、ワークツリーを使えばより多くのことを並行して行うことができます。これは GitHub Copilot アプリのデフォルトモードであり、多くの他の現代ツールでも同様です。 しかし、落とし穴はあるのでしょうか？ ワークツリーは確かに多くの問題を解決しますが、注意すべき点も確実に存在します。 依存関係の肥大化：各ワークツリーフォルダには、プロジェクトの依存関係のコピーがそれぞれ必要になります。複数の場所で npm install や pip install を実行すると、コンピュータのストレージがすぐに一杯になってしまう可能性があります。 フォルダ管理：時間とともに親ディレクトリが散乱しないよう、ワークツリーフォルダを削除する必要があります。GitHub Copilot アプリなどのアプリはこれを自動で処理することが多いですが、ターミナル上で直接操作している場合は、自分自身で行う必要があるかもしれません。 グローバルな .gitignore の要件：メインのリポジトリディレクトリ内にワークツリーフォルダを作成した場合、誤って追跡されないように手動で .gitignore に追加する必要があります。これらのワークツリーをメインのリポジトリの外に作成することも可能であり（多くのアプリがデフォルトでこれを行いますが）、その点は注記しておく価値があります。 ブランチ制限：Git はデータ破損を防ぐため、同じブランチを同時に 2 つの異なるワークツリーでチェックアウトすることを禁止しています。 GitHub Copilot アプリでワークツリーを使用するにはどうすればよいですか？ 素晴らしい質問ですね！素晴らしいのは、これらがそのままの状態で「すぐに使える」ことです。アプリを開くと、ホーム画面で新しいセッションを実行する場所を尋ねるドロップダウンが表示されます。デフォルトは新しいワークツリーです。 ![image](https://github.blog/wp-content/uploads/2026/06/Screenshot-2026-06-16-at-1.35.20-PM.png?resize=924%2C819) その後、新しいセッションを開始すると、アプリの上部にあるセッション名をクリックできます。そうすると、生成された（楽しい！）ワークツリーの名前と、それが配置されているバスタブ、そのワークツリーが対象とするプロジェクト、そしてあなたが行った変更に関する詳細が表示されます。 ![image](https://github.blog/wp-content/uploads/2026/06/Screenshot-2026-06-16-at-1.36.45-PM.png?resize=877%2C331) 簡単すぎてレモンを絞るほど！ ワークツリーを使うべきでしょうか？ 私ができる限りシニア開発者としての回答をします：それはケースによります！あなたは一方のやり方を好むかもしれませんし、他方のやり方を好むかもしれません。並行して行う作業がそれほど多くなく、ブランチやスタッシュというメンタルモデルが好きかもしれません。あるいは、今後はワークツリーのみを使うようになるかもしれません。両方を使いたいと思うこともあるでしょう。 世界はあなたのもの、そして GitHub Copilot アプリで今日からそれらすべてを試すことができます。 「git worktrees とは何か、なぜ使うべきか？」という投稿は、最初に The GitHub Blog で公開されました。

Git のワークツリーとは何か、そしてなぜ使用するべきなのか？

背景や根拠まで確認しますか？

調べる

選ぶ

サイト