Git Worktreeのすすめ

はじめに

これはヤプリ&フラー 合同アドベントカレンダー 2025の5日目の記事です。

前置き

今年から私はサーバーサイドエンジニアとして働き始め、1日6,7時間はプログラミングやレビューを行っている生活になりました。
好きにプログラミングをしていた学生時代とは違い、効率的に開発することが(たぶん)求められています。また、入社後からはGitHub Copilotなどのコード生成AIの活用も行ってきました。
そこで、効率化を図るために同じリポジトリを複数クローンしていたのですが、類似した機能のGit Worktreeがあることを知り、更に効率的になった(と感じている)ので紹介したいと思います！

概要

Git Worktreeは前置きでも話したように、同じリポジトリを複数クローンしている状態に似ています。
使い方は簡単で、Git支配下のディレクトリ内でgit worktree add {path}を実行すると指定したパスにコピーされたようなディレクトリが作成されます。公式のドキュメントでは、これをメインワークツリー("main worktree")からリンクドワークツリー("linked worktree")が作られると書かれています。

試しに適当なディレクトリを作成して試してみます。

cd tekito/ # 適当なディレクトリに移動

# メインワークツリーの作成(普通にGitリポジトリの作成)
mkdir main
cd main
git init .
echo "example file" > example.txt
git add example.txt && git commit -m "add example.txt"

# リンクドワークツリーの作成
git worktree add ../linked

git worktree add ../linkedのこれだけで、tekito/linked/が作られています。
中には最初のコミットで追加したファイルtekito/linked/example.txtがあります。
更に、メインワークツリーとリンクドワークツリーの比較を以下のコマンドで試してみます。

cd .. # tekitoディレクトリに移動
cd main/ && git branch && git log --oneline && cd ..
cd linked/ && git branch && git log --oneline && cd ..

$ cd main/ && git branch && git log --oneline && cd ..
+ linked
* master
4a2579e (HEAD -> master, linked) add example.txt

$ cd linked/ && git branch && git log --oneline && cd ..
* linked
+ master
4a2579e (HEAD -> linked, master) add example.txt

linkedというディレクトリ名でリンクドワークツリーを作成したので、mainブランチから派生したlinkedという名前のブランチになっています。
こうなってしまえば、後はlinkedディレクトリでも普段通りのGit操作をするだけです。

また、以下コマンドでlinkedディレクトリを削除できます。(ブランチは残ったままです。)

git worktree remove linked

ワークツリーは作業ごとに作成していく想定で書かれていますが、個人的にはワークツリーを2つほど作成して作業ごとに3つのディレクトリを使い分けています。

ユースケース

ここからは私が実際に活用している使用例を記載していきます。

レビュー・修正

プログラムを書いている途中でレビューをする場合が良くあると思います。
私は始業後と就業前にレビューをすることが多いのですが、担当している作業が日を跨ぐ場合には書きかけのプログラムがローカルリポジトリに残っていることもしばしばあります。
また、同じタイミングで自分が出したプルリクエストへのレビューを確認し、必要があれば修正することもあります。

今までは一度スタッシュを行ってレビュー対象のブランチに移動し、対応後に元のブランチに移動してスタッシュから復元していました。

git stash push .
git switch targer-branch
# レビュー or 修正
git switch -
git stash pop stash@{0}

Tips: git switch -で前にいたブランチへ戻れる

Git Worktreeを使えば、以下のようにスタッシュに戻さずレビューや修正が出来ます。

git worktree add ../target target-branch
code ../target
# レビュー or 修正
git worktree remove target

生成AIを利用した作業とレビュー・修正の並列化

最近は生成AIを利用した実装をすることも多くなってきました。この際、AIがコードを生成する待ち時間の発生がしばしばあります。
その待ち時間を利用して、別ワークツリーでレビューや修正作業を行っています。VSCodeを二つ開いておけば、コード生成とレビューを交互に行うこともできます。

生成AIを利用した作業の並列化

生成AIを複数走らせることもできます。
依存関係がある実装の際でも、抽象クラスや関数定義(Go言語ならインターフェース)のみを先にコミットし、そこから派生ブランチのワークツリーを作ることで対象の関数の実装と対象の関数を使用する別関数の実装を並行して行えます。

以下はクリーンアーキテクチャでユースケースとインフラストラクチャを並列で実装する図例です。

この例ではコミット後にgit rebase --ontoを使用していますが、これはワークツリーでのブランチの状態は共有されているため可能です。
ブランチを2つクローンする場合では、一度インフラのブランチをリモートにプッシュして、ユースケースのブランチでgit pull origin Infra --rebaseする面倒くさい工程が必要です。

私が3つのディレクトリで作業しているのは、上記の2つのAIでの並列実装に加えてレビューを行うブランチを別で用意しているためです。

少し不便な点

Git管理外のファイルがコピーされない

.gitignoreでGitの管理外になっているファイルはコピーされないので.vscode/や.envなどは元のブランチからコピーする必要があります。
私は毎度設定するのが面倒なので、ワークツリーは削除せずに一度設定を行ったワークツリーを使いまわして作業しています。

解決策を知っている方がいれば教えてください

rebaseなどの際に開くエディターがメインワークツリーのIDEになる

Gitで使うエディターをVSCodeにしているのですが、git rebaseなどを実行するとメインワークツリーのVSCodeに編集画面が現れます。
(解決策はある気がするのですが、面倒で調べていない)

おわりに

生成AIが台頭してきた現代ではGit Worktreeを使うことで、効率的に作業を実施することができると思います。
これからも効率化もとい、面倒回避に向けてGitや生成AIなども学んでいこうと思います。