🤖

Git Worktreeで実現するVSCode x GitHub Copilot並列実装環境

Yorinton

2025/11/11に公開

 はじめにこの記事では、ローカル開発環境で VSCode を複数立ち上げて、GitHub Copilot などの AI アシスタントを使った並列実装が可能な環境構築について紹介しようと思います。
これまで弊チームでは、1 つの VSCode ウィンドウで作業を行っていました。

ただ、この方法だとAIが長い処理を行っている間に待ち時間が発生してしまい、もどかしい気持ちになることがちょくちょくありました。

特に、差し込みの不具合対応が必要になった場合や、複数のエンドポイントを同時に実装する必要がある案件では、ローカルでもAIに並列で実装させられたら良いなと思っていました。
本記事で紹介する仕組みを活用することで、複数のブランチで同時並行して開発を進めることができ、AIアシスタントの能力をより引き出せるようになるんじゃないかと考えています。

 前提
 前提となる環境とツール今回、並列実装環境を構築するにあたり、前提となるツールやコマンドは以下になります。
Node.js x npm
Visual Studio Code (codeコマンドの有効化)
Git（git の worktree 機能を活用）
必要な Git コマンド

git worktree add: 同じリポジトリの異なるブランチを別ディレクトリに作成

git worktree list: 作成された worktree の一覧表示

git worktree remove: 不要になった worktree の削除

git worktree prune: worktree 情報のクリーンアップ
検証済みの環境

現在のところMacでのみ検証済み

 具体的な仕組みこの並列実装環境は、Git の worktree 機能を核として構築されています。

 基本的な概念通常の Git リポジトリでは、1 つのワーキングディレクトリに対して 1 つのブランチがチェックアウトされます。しかし、worktree 機能を使用することで、同じリポジトリの異なるブランチを別々のディレクトリに同時にチェックアウトできます。
例えば、以下のような構造を作成できます。
~/projects/
├── my-project/                    # メインのリポジトリ（developブランチ）
├── my-project-feature-api/        # APIブランチ用worktree
├── my-project-feature-frontend/   # フロントエンドブランチ用worktree
└── my-project-hotfix-bug/         # 緊急修正ブランチ用worktree

 自動化の仕組み手動で worktree を作成すると、以下の問題が発生し、都度環境を作るが手間です。
各ディレクトリで依存関係のインストールが必要
設定ファイルの手動コピーが必要
開発環境の立ち上げが手間
削除時のクリーンアップが複雑
これらの問題を解決するため、以下の処理を自動化したスクリプトを作成しました。

ブランチ存在確認と作成: 指定されたブランチが存在しない場合は自動作成

worktree 作成: 各ブランチ用のディレクトリを自動生成

設定ファイル自動配置: 環境設定ファイルなどgit管理されていないファイルを各ディレクトリにコピー

依存関係自動解決: 各ディレクトリでnpm ciを実行

VSCode 自動起動: 各ブランチ用の VSCode ウィンドウを起動

 作成したスクリプトのイメージ
 セットアップスクリプト並列開発環境を構築するメインスクリプトです。

一部コードは端折ってますのでそのまま利用はできませんが参考程度に見て頂ければと思います。
# ファイル名: setup.sh

#!/bin/bash
set -e

# 設定項目
PROJECT_NAME="my-project"
MAIN_BRANCH="develop"

echo "並列開発環境のセットアップを開始します..."

# 各ブランチの処理ループ
# この中でgit worktreeコマンドでブランチ毎の環境を作成します
for BRANCH in "$@"; do
  # ブランチ名を元に各ブランチのソースが入るディレクトリ名を作成
  TARGET_DIR="../${PROJECT_NAME}-${BRANCH}"

  # ブランチ存在確認とworktree作成
  if [ -d "$TARGET_DIR" ]; then
    echo "既にworktreeが存在します"
  else
    echo "worktreeを作成中"
    git worktree add $TARGET_DIR $BRANCH

    # ここでlocal用の環境変数ファイルなど、git管理していない必要ファイルのコピー処理を行います
    # 依存関係のインストール
    npm ci
  fi

  # VSCode起動
  # - これによりブランチ毎にVSCodeが起動されます
  code --new-window "$TARGET_DIR"
done

echo "セットアップが完了しました"
利用時は以下のように利用します。
./setup.sh <branch1> <branch2>
スクリプト実行後は以下のようにブランチ毎にディレクトリが作成され、それぞれのディレクトリ毎にVSCodeが起動されます。
~/projects/
├── my-project/                    # メインのリポジトリ（developブランチ）
├── my-project-branch1/
└── my-project-branch2/

 クリーンアップスクリプト不要になった worktree を削除するスクリプトも作成しました。

こちらも、一部コードは端折ってますのでそのまま利用はできませんが参考程度に見て頂ければと思います
# ファイル名: cleanup.sh

#!/bin/bash
set -e

PROJECT_NAME="my-project"

# 引数チェック処理

echo "worktreeクリーンアップを開始します"

# 各ブランチの削除処理
for BRANCH in "$@"; do
  TARGET_DIR="../${PROJECT_NAME}-${BRANCH}"

  if [ -d "$TARGET_DIR" ]; then
    # 削除確認プロンプト
    read -p "ディレクトリを削除しますか？ (y/N): " CONFIRM

    if [[ "$CONFIRM" =~ ^[Yy]$ ]]; then
      # worktree削除処理
      git worktree remove "$TARGET_DIR" --force || {
        rm -rf "$TARGET_DIR"
      }
    fi
  fi
done

# worktree情報のクリーンアップ
git worktree prune
echo "クリーンアップが完了しました"
利用時は以下のように利用します。
./cleanup.sh <branch1> <branch2>

 想定利用シーンまだこの環境を作ったばかりであまり試せてはいませんが、以下のようなシーンで活用できればと考えています。

複数エンドポイントの同時実装: エンドポイント①とエンドポイント②を別々のVSCodeで立ち上げて、AIに並列で実装させる

フロントエンドとバックエンドの同期開発: APIとUIを別々のVSCodeで同時に開発する

緊急対応と通常業務の両立: 差し込みの不具合対応を別のVSCodeでAIに処理させながら、自分は担当案件の実装を継続する

実験的な機能開発: メイン開発を継続しながら、新技術の検証を並行実施する

 懸念点・注意点
 DBは１つ各ディレクトリで同じ環境変数ファイルを使っており同じローカルDBに接続されているため、例えばローカルでAPIの自動テストを実行する場合、他のブランチと実行タイミングが被らないように注意する必要があります。

 リソース消費の問題ブランチ毎にディレクトリを作成し、それぞれでnpm ciを実行するため、並列数が多いとストレージなどPCリソースを大量に消費する可能性があります。
ただ、現状では最大3並列程度を想定しており、自分の環境では問題になっていません。

 コードレビューのボトルネック並列実装により開発速度は向上しますが、人間によるコードレビューがボトルネックになる可能性があります。

レビュー待ち時間の増加: 複数のプルリクエストが同時に作成される

レビュー品質の維持: 短時間で多くのコードをレビューする必要性
一方で、他の人のレビューを行なっている間も他の案件を進められるので３並列程度ならそこまで大きな問題にはならないんじゃないかと思っています。

また、弊チームではAIによるコードレビューを行なっていますが、このレビュー精度を上げてAIにレビューを任せる割合をどの程度増やしていけるかが１つの課題になりそうです。

 今回考慮しなかったこと
 tmux の利用多くの技術記事やSNSの投稿でtmuxを活用した並列開発が紹介されており、最初は検討しました。

tmuxを使用することで以下のメリットがあります。

ターミナルセッション管理: 複数の開発セッションを効率的に管理

セッションの永続化: 接続が切れてもセッションが継続

画面分割機能: 1つのターミナルで複数の作業領域を確保
しかし、今回はローカル開発の並列化を第一目標としたため、tmuxの利用は必須ではないなと感じ使いませんでした。

 pnpmの活用pnpmはnode_modulesをハードリンクで共有する仕組みにより、以下のメリットがあります。

ディスク容量の節約: 重複するパッケージを共有

インストール速度の向上: 既存パッケージの再利用
この仕組みは並列開発環境にとって魅力的でした。ただ、現状npmを使っているのと実際にnpmで3並列の検証を行った結果、現在の開発環境では特に問題が発生しませんでした。また、チームメンバーへの早期展開を優先したため、既存のnpmをそのまま使用することにしました。
今後、より多くの並列数が必要になった場合や、ディスク容量が課題となった場合には、pnpmへの移行を検討する予定です。

 まとめ現段階では、人間のタスクスイッチングコストやコードレビューにかかる時間を考慮すると、3並列程度がバランスの良い開発スタイルだと考えています。(現状はAIの提案に対して人間がチェックする体制のため)
今後はこの仕組みをチームで運用してみてどの程度活用できるか試しつつ、ローカルでの並列実装環境が、チーム開発において標準的な開発手法として定着するよう、継続的な検証と改善を行っていきたいと考えています。

GVATECHブログ

GVA TECH株式会社のテックブログです。

はじめに

前提

前提となる環境とツール

具体的な仕組み

基本的な概念

自動化の仕組み

作成したスクリプトのイメージ

セットアップスクリプト

クリーンアップスクリプト

想定利用シーン

懸念点・注意点

DBは１つ

リソース消費の問題

コードレビューのボトルネック

今回考慮しなかったこと

tmux の利用

pnpmの活用

まとめ

Discussion