Git の worktree 機能は、ブランチを切り替えることなく複数の作業ディレクトリを同時に扱える素晴らしい機能です。 しかし、ただ実際に運用してみるとそれだけでは使えない場面がほぼです。
- .gitignore されている .env ファイルが新しいワークツリーにコピーされない
- 複数のワークツリーでサーバーを起動すると、ポート番号が衝突する
- ワークツリー作成後に毎回 npm install を叩くのが面倒
これらの課題を解決し、ワークツリーの作成からクリーンアップまでをスムーズにするために作成したのが git-wt zgt です。
(git-wtからzgtにrenameしました)
git-wt の主要機能と利用例
git-wt は git worktree のラッパーとして動作し、開発者のコンテキスト切り替えに寄り添う機能を提供します。
1. ワークツリーの追加と設定の自動同期 (add)
通常の git worktree add では、.env などの設定ファイルはコピーされません。git-wt を使うと、無視されているファイルを自動的に特定して新しいワークツリーにコピーします。
# feature-login ブランチを新しいワークツリーで開始 git-wt add feature-login
便利なポイント:
- パスの指定を省略すると、自動的に ../{プロジェクト名}-{ブランチ名} にディレクトリが作成されます。
- 元のディレクトリにある .env やローカルの設定ファイルがそのまま引き継がれるため、すぐに npm start が可能です。
2. 進捗の可視化と GitHub 連携 (list)
list (または ls) コマンドは、現在存在するワークツリーの状態を一目で把握できるようにします。
git-wt list
表示例:
../my-pj-main a1b2c3d [main] ../my-pj-feature-login e5f6g7h [feature-login] PR:#123 [DRAFT] [DIRTY] ../my-pj-fix-bug i9j0k1l [fix-bug] PR:#125 [OPEN]
gh コマンドと連携し、Pull Request の状態(Draft, Open, Merged)や、そのワークツリーに未コミットの変更があるか (DIRTY) を表示します。どの作業がどこまで進んでいるかが直感的に分かります。
3. ポート番号の自動割り当て (env / ports)
複数のワークツリーで同時に開発サーバーを立ち上げる際、最大の課題はポートの衝突です。git-wt は各ワークツリーに一意の「ポートインデックス」を割り当てます。
設定例 (git-wt.config.yaml):
ports: api: 8080 web: 3000
利用シーン: ワークツリー A にインデックス 0、ワークツリー B にインデックス 1 が割り当てられている場合:
# ワークツリー B に移動して環境変数を読み込む cd ../my-pj-feature-login eval $(git-wt env) # $API_PORT は 8081 (8080 + 1) # $WEB_PORT は 3001 (3000 + 1) に自動で設定される npm start
これにより、複数のブランチを同時に実行しても、ポート番号を手動で書き換える必要がなくなります。
4. カスタムフックによる自動化 (hooks)
ワークツリーの作成時や削除時に、任意のコマンドを実行できます。
hooks: add: - "npm install" - "tmux new-window -n [{{.Repo}}]{{.Branch}} -c {{.Path}}" rm: - "echo 'Cleanup for {{.Branch}} done.'"
ワークツリーを作成した瞬間に依存パッケージがインストールされ、エディタやターミナルのウィンドウが準備されます。
導入と設定
Go 言語で書かれているため、シングルバイナリで動作します。
brew install mocyuto/tap/git-wt
設定はプロジェクトルートの git-wt.config.yaml で行います。プロジェクトごとに無視したいファイルや、必要なポート、フックを定義できます。
まとめ:LLM 時代の「車輪の再発明」
git worktree のラッパーツールは、世の中に既にいくつか存在します。それでもあえて自分自身でツールを作ることにしたのは、LLM(Claude や ChatGPT)の登場によって、「自分専用にカスタマイズされたツール」を爆速で作り上げることが可能になったからです。
既存のツールに自分のワークフローを合わせるのではなく、今回「車輪の再発明」を恐れず、自分の理想とする動きを LLM と対話しながらコードに落とし込む。 自分にとって最高の道具を自作していくことが今後はどんどん一般的になっていくのかなと思っています。