コンテキストスイッチという「死」を撲滅せよ：Git Worktreeで開発体験を極限まで加速する
君たちのPCの中に、何個のプロジェクトディレクトリが存在している？
`feature/a` を修正している最中に、「至急、本番のバグを直してくれ」と言われ、重たいビルドが走っている最中のディレクトリを捨てて `git checkout` を叩く。そして戻ってきたら、またゼロからビルドが始まる……。
その「待ち時間」は、君たちの脳のメモリを確実に浪費させている。
今回は、Gitの隠れた奥義 `git worktree` を使い、コンテキストスイッチのコストを物理的にゼロにする方法を伝授する。これは単なるTipsではない。君の脳内のタスク切り替えコストを排除し、開発の「フロー状態」を維持するための戦略的投資だ。
—
1. なぜ `git checkout` は「悪」なのか？
`git checkout` は、同じディレクトリ内でファイルの入れ替えを行う。これには致命的な欠点がある。
- ビルド成果物のパージ: `node_modules` や `target` ディレクトリが汚染され、再ビルドが必要になる。
- IDEのインデックス再構築: VS CodeやIntelliJが「ファイルが全部変わった！」と勘違いし、数分間、補完や検索が効かなくなる。
- 精神的コンテキストの断絶: 「あ、さっきまで何を考えてたんだっけ？」というあの隙間時間こそが、生産性の最大の敵だ。
`git worktree` は、一つのリポジトリ（.git）を共有しつつ、複数のディレクトリで同時に異なるブランチを展開する。つまり、作業ディレクトリを「物理的に分離」して並列化するのだ。
—
2. 実践：Worktreeの爆速セットアップ
まず、今のリポジトリで以下のコマンドを叩いてみてくれ。
修正用ブランチを別ディレクトリに展開
構文: git worktree add <ディレクトリ名> <ブランチ名>
git worktree add ../project-fix-bug bugfix/critical-issue
これで、親ディレクトリに `project-fix-bug` が出現し、即座にそのブランチで作業を開始できる。メインのディレクトリ（`main`）を汚すことなく、並行して作業が進められるのだ。
チーム開発で役立つ「自動化スクリプト」
毎回コマンドを打つのは面倒だ。`.bashrc` や `.zshrc` に以下の関数を仕込んでおけ。
Worktreeを爆速で作成し、移動するエイリアス
function gwa() {
local branch=$1
local dir=”../${PWD
/}-$branch”
git worktree add “$dir” “$branch”
cd “$dir” || return
}
—
3. 開発スピードを底上げする「神」ツール＆設定
絶対に入れるべきプラグイン：`fzf` + `ghq`
ディレクトリ移動をコマンド一つで完結させるエコシステムを構築する。
- fzf: インタラクティブなファジー検索。`git worktree list` の結果を fzf に流し込めば、一瞬でコンテキスト間をジャンプできる。
- ghq: プロジェクトの管理を標準化する。`git worktree` と組み合わせることで、どのディレクトリに何があるかという「管理コスト」すらゼロになる。
VS Code設定の共有（.vscode/settings.json）
Worktreeを使うと、IDEの設定が分散しがちだ。以下の設定をリポジトリルートに配置し、全てのWorktreeで参照させるのが鉄則だ。
{
// 共通の排除設定。Worktree間の衝突を防ぐ
“files.watcherExclude”: {
“/.git/worktrees/“: true,
“/node_modules/“: true
},
// Worktreeのルートを自動認識させる設定
“git.scanRepositories”: [
“.”,
“../”
]
}
—
4. 伝説のエンジニアが教える「運用ルール」
どれだけツールが強力でも、ルールがなければカオスになる。現場で震えるほど役立つ「Worktree運用の極意」を授けよう。
1. 「使い捨て」を恐れない:
Worktreeは単なる一時的な作業場だ。作業が終わったら `git worktree remove <ディレクトリ>` で即座に破棄する。汚れた環境を残さないことが、心身の健康を保つ秘訣だ。
2. `.gitignore` の再確認:
Worktreeをリポジトリの外に作ると、IDEがルートの `.gitignore` を見失うことがある。必ずルートディレクトリに一元管理の仕組みを作れ。
3. CI/CDパイプラインとの連携:
CIツール（GitHub Actions等）には、ワークスペースをクリーンに保つキャッシュ戦略がある。ローカルでのこの並列作業を、CI上でも `actions/cache` を使って「依存関係のキャッシュ」として再現する。これでローカルとCIのビルド時間が同期される。
—
最後に：君は何のためにコードを書いている？
`git worktree` を使う理由は、Gitの機能に詳しいと自慢するためではない。「君が本来やるべき仕事（ビジネスロジックの改善や設計）」に集中するための時間を、1秒でも多く創出するためだ。
ツールに振り回されるな。ツールを飼いならし、君の脳の「思考の帯域」を最大化しろ。明日から、君のPCには常に「準備万端な複数のプロジェクト」が並んでいるはずだ。
さあ、コマンドを叩け。そして、思考を止めるな。