この記事は 株式会社TRAILBLAZER Advent Calendar 2025 の 20日目の記事です。
ソリューション事業部の @yosimaeta です。
長年 git stash を何の疑問も持たずに使っていましたが、2年ほど前に git worktree をたまたま知り、今まで知らなかったことを恥ずかしくなるぐらい衝撃を受けました。今ではこれ無しでお仕事できません。
紹介し尽くされている worktree の基本は他の記事にお任せして、ここでは私の使い方と気づいたことを紹介していきたいと思います。
目次
- 私の構成
- 使っていて気づいたこと
- おわりに
1. 私の構成
worktree の配置方法は人それぞれだと思いますが、私は以下のような構成にしています。
ディレクトリ構成
my-project/ # main ブランチ
├── .git/
├── src/
├── package.json
└── z-git-worktree/ # ← worktree 置き場
├── feature/awesome-feature/ # feature/awesome-feature
├── feature/login-fix/ # feature/login-fix
├── releases/release20251220/ # release/release20251220
└── sandbox/codecheck/ # ローカル検証用
リポジトリ内に z-git-worktree というフォルダを作り、その中に worktree を配置しています。
z- を付けているのは、ファイルツリーの一番下に表示されるようにして他の邪魔にならない位置に入れたかったためです。普段の開発では目に入らない位置になります。リポジトリの外に置く方法もありますが、同じような名前のフォルダが並ぶのを避けたかったので、この形に落ち着きました。
グローバル gitignore
z-git-worktree が push されないよう、グローバルな gitignore に追加しています。
# ~/.config/git/ignore
z-git-worktree/
リポジトリごとの .gitignore を編集する必要がないので、どのプロジェクトでも同じ運用ができます。
mise を使っている場合
mise でツールバージョンを管理しているのですが、worktree 内に入るたびに mise trust を求められてしまいます。
$ cd z-git-worktree/feature-login-fix
mise WARN .../z-git-worktree/feature-login-fix are not trusted
これを避けるため、プロジェクトフォルダ全体を trust しておくと楽です。
# ~/.config/mise/config.toml
[settings]
trusted_config_paths = [
"~/projects/hoge-project/z-git-worktree",
]
2. 使っていて気づいたこと
stash は worktree 間で共有される
あるとき、feature ブランチの worktree で git stash list を実行したところ、main で stash したものが見えました。
# feature-a の worktree にて
$ git stash list
stash@{0}: WIP on main: abc1234 作業中のもの
worktree は .git ディレクトリを共有しているため、stash も共有されます。
stashを使う回数は減りましたが、実装中に変更が大きくなり過ぎて「これ別のブランチにしてPR別にしておこうかな」と思うときがあります。そのファイルを stash してフォルダ移動して別のブランチで apply しちゃえばいいので楽です。きれいな状態のブランチで展開するのでそういう安心感もあります。
# main で stash
git stash push -m "この変更は feature-b で使う"
# feature-b の worktree に移動して
cd ../z-git-worktree/feature-b
# apply
git stash apply stash@{0}
プロンプトにブランチ名を出しておくと迷わない
worktree を複数開いていると、「今どこで作業してるんだっけ」となることもあります。
使っている方も多いと思いますが、私は Oh My Zsh を使っていて、プロンプトにブランチ名が表示されるようにしています。テーマを指定するだけ（でもないですが）比較的簡単に設定できてカッコいい見た目が出来上がります。
# ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"
VSCode であれば、通常は左下にブランチ名が表示されますし、worktree ごとに別ウィンドウで開けば、ウィンドウ名からも判別できます。
フォルダを先に削除してしまった場合
通常は git worktree remove で削除するんですが、rm -rf で先にフォルダを削除してしまうこともありました。コマンドに慣れるまでの使い始めのときは何度かやりました…
$ rm -rf z-git-worktree/feature-old
その後、同じブランチで worktree を作ろうとすると、こうなります。
$ git worktree add z-git-worktree/feature-old feature/old
fatal: a branch named 'feature/old' already exists
Git 側には参照が残っているためです。git worktree prune で解消できます。
# 存在しない worktree への参照を削除
$ git worktree prune
# 確認
$ git worktree list
3. おわりに
git worktree を使い始めてから、ブランチ切り替えに伴う stash の管理から解放されました。レビュー対応と自分の作業を並行して進められるのも便利です。
何より main で作業するリスクがなくて、気づいたら main だった、こわっ、、ということがなくなったのが一番ですね。
とはいえ、worktree が万能というわけではありません。フォルダを分ける以上、worktree を作るたびに npm install などの初期化が必要になります。フォルダが増えると管理も必要ですし、ツールによっては相性の問題もあります。
道具は適材適所で。この記事が何かの参考になれば幸いです。
株式会社TRAILBLAZERでは、一緒に働くエンジニアを募集しています。
少しでも興味を持っていただけた方は、ぜひ採用ページをご覧ください。