なぜこの記事を書くことにしたのか
私は実務経験が2年3か月目に突入した、SES企業勤めの中年手前エンジニアです。
現在、フロントエンドに React、バックエンドに Spring Boot を使用して、初のポートフォリオを作成しています。
ポートフォリオのテーマはありきたりかもしれませんが、中間テーブルを活用したDB設計 や Dockerによるモノレポ管理 などを学習する目的で、Twitterクローンアプリ を作成中です。
今回は、フロントエンドとバックエンドを共通のリポジトリで管理し、Dockerで統合運用する構成を採用しました。
実は、以前参画していた現場でもモノレポ構成は採用されていたのですが、そのときはフロントエンド専任だったため、バックエンドやGit運用の裏側に触れる機会はありませんでした。現場のルールに従うだけで、特に大きな課題を感じることもなかったのです。
しかし今回のポートフォリオでは、Docker・DB操作・バックエンド実装と、これまで未経験だった領域にも挑戦しています。
「モノレポならとりあえず1つのリポジトリで管理すればいいだろう」と安直に始めてみたところ、実際に進める中で 想定外の問題 に直面しました。
ChatGPTに相談しながら原因を探っていく中で、「git worktree」を活用する必要があるという知見にたどり着いたのです。
この発見が非常に有用だったため、同じようにモノレポ構成で詰まりやすい人の助けになればと思い、今回その体験を備忘録としてまとめることにしました。
開発環境について
開発環境は以下になります。
| 項目 | 内容 |
|---|---|
| OS | Windows |
| フロントエンド | React（Visual Studio Code） |
| バックエンド | Spring Boot（IntelliJ IDEA） |
| コンテナ環境 | Docker（Monorepo構成） |
モノレポのディレクトリ構成について
以下で構成されています。
TwitterCloneApp
├── .idea
├── backend(SpringBoot,IntelliJ)
├── frontend(React, VSCode)
├── .dockerignore
├── compose.yaml
└── README.Docker.md
とりあえず、から何に困ったのかという話
今回の開発では、フロントエンドを VSCode、バックエンドを IntelliJ IDEA で進めています。
それぞれのエディタを分けて使うのは今回が初めてでした。
フロント側はコンポーネント周りをざっくり作成済み。
一方で、バックエンドは設計をざっくり起こして「さて、実装に手をつけてみるか」と思ったところで、事件が起きました。
💥 あれ？ブランチが勝手に変わってる！？
VSCode側でブランチをチェックアウトしたところ、IntelliJ 側のブランチも同時に切り替わっていた のです。
フロント側のVSCodeを「新しいブランチ」ブランチを新規作成チェックアウトしたら....
あれ、IntelliJ側のカレントブランチも同じブランチにチェックアウトされている！？....と
どちらのエディタから見ても 同じディレクトリ（同じリポジトリ）を参照しているため、ブランチが共有されていた ということ。
モノレポ構成で、かつ2つのエディタを同時に使うのは初だったのですが、
Gitに関して解決策が全然浮かばないどん詰まりをするのも久々で、「なんで連動して動くんだああ……？」と頭が真っ白になりました。
ちなみにここまで書いていて恐らくわかりきってることになりますが、同一のディレクトリで同一のファイルを編集(例えばvscodeでintelliJのjavaソースコードを書き換える)してしまうと、当然ですがリアルタイムでIntelliJで管理してるJavaソースコードも変更されます。
🧩 原因を調べてみると…(ChatGPTに聞いて調べてみたところ)
「.git ディレクトリ配下では、同時に管理できるカレントブランチは1つだけ」
という仕様があることを知りました。
つまり、「1つの .git(親ディレクトリに配置されている.git) で複数ブランチを同時に扱うことはできない」というルールです。
💡 解決の方向性を自分で考えてみた
-
モノレポ管理をやめる（やめたくない）
-
フロントとバックで別々にリポジトリをクローンし、リモートでマージして運用する(問題はなさそうだけどなんとなく違和感がある)
……うーん、どちらもしっくりこない。
自分の知見では打開策が見つからず、どん詰まり状態でした。
💡 解決の方向性
そしてこの調査していたところ、この仕様を回避するには、git worktree を使うのが最善だという結論に至りました。実際に導入してみると、モノレポ構成でも「フロントとバックで別ブランチを動かしながら並行作業」
ができるようになり、今のところ違和感が無くなったなという感じになれました。
git worktreeとは何か
「1つのローカルリポジトリ(.git)から、複数の作業用ディレクトリを同時に使えるようにする仕組み」のことです。
普通のGitの場合
- フォルダで管理できるカレントブランチは1つだけ。
- 別のブランチで作業をしたい場合には、そのたびに一時コミットやstashを実行してcheckoutする必要がある
- フロント側はdevelop, バックエンド側はfeatureのような、並行作業ができない。
Git worktreeの場合
- 1つのリポジトリから複数の作業ツリー(ワークツリー)を生やすことができる
- 各ワークツリーが別ブランチと独立してチェックアウトができる
- 同じリポジトリを複数回クローンしなくても、別ディレクトリで作業が可能
git worktreeのメリットのまとめ
| 項目 | 内容 |
|---|---|
| 並行作業 | 複数ブランチを同時に扱える(都度stash, 雑な一時コミット, チェックアウトが不要) |
| ディスク効率 | .gitが共有されるため、容量を節約可能 |
| 一貫性 | どのワークツリーでも同じ.gitを参照するので、リモート設定などが共通 |
🌱 ちょっとした補足：名前の由来と実際の感覚
worktree はその名の通り、**「作業ツリー（＝幹）」**のようなイメージです。
そこから 各ブランチ（＝枝） が伸びており、
それぞれの枝で独立した作業ができる、という構造になっています。
つまり、大分類的なカテゴリを分け、複数の枝を同時に育てられるわけです🌳
私自身、以前は
「PRレビュワーとしての動作確認, コンポーネント追加, 別画面の開発」
を同時期に進めていたことがあり、そのたびに 鬼のように checkout を繰り返していました。
今思えば、あのとき git worktree を使えていれば、
もっと効率的に、そしてストレスなく開発を進められていた気がします。
実際にgit worktreeを使ってみる
拡張子がjsですが、モノレポディレクトリを作成してみました。
sample
├── .git
├── backend
│ └── index.js
└── frontend
└── index.html
まずはgit worktree未使用で動作確認
同一のディレクトリを参照している状態でターミナルを確認します。
カレントブランチは双方masterになっています。
VSCode
IntelliJ
IntelliJ側のターミナルで新規ブランチ作成チェックアウトを行います。すると....
VSCode側も同一のディレクトリを参照してしまっているので、カレントブランチがfeature_samsamにチェックアウトされていることが分かります。
先述した「フォルダで管理できるカレントブランチは1つだけ」というルールに従っている点ということが分かりやすいかと思います。
Git worktreeを導入する
先ほどの構成をそのまま使用して
- 統合worktree(既存)
- フロントエンド開発用worktree(追加)
- バックエンド開発用worktree(追加)
2個のworktreeを追加します。
sample
├── .git
├── backend
│ └── index.js
└── frontend
└── index.html
※新規にdevelopブランチにチェックアウトして、「first commit」を残しています。
カレントディレクトリがsampleの状態で、以下のコマンドを実行してみましょう。
基本構文
パターン①：既に存在するブランチを指定する場合
既存ブランチ（例：develop）をチェックアウト済みの作業ディレクトリとして追加します。
git worktree add <新しいディレクトリ名> <ブランチ名>
パターン②：まだ存在しないブランチを新規作成したい場合
新しいブランチを作成し、その状態でチェックアウトされたディレクトリを作成します。
git worktree add <新しいディレクトリ名> -b <ブランチ名>
📝 補足
<ブランチ名> はそのワークツリーで使用したいブランチを指定します。
-b オプションを付けると、「現在のブランチをベースに新規ブランチを作成してチェックアウト済み状態で追加」されます。
付けない場合は、既に存在するブランチを指定して展開します。
今回はパターン②を使用してみます。
git worktree add ../frontend-directory -b front_develop (フロントエンド用worktreeを作成)
git worktree add ../backend-directory -b back_develop (バックエンド用worktreeを作成)
ターミナル上で
git worktree list
を実行すると以下のようにworktreeが作成されていることが分かりました。
C:/Users/l/OneDrive/デスクトップ/sam/sample c232174 [develop]
C:/Users/l/OneDrive/デスクトップ/sam/backend-directory c232174 [back_develop]
C:/Users/l/OneDrive/デスクトップ/sam/frontend-directory c232174 [front_develop]
ターミナル上で「git branch」を実行してみると以下のように出力されています。
＊ はいわずもがなカレントブランチ
＋ は「他のworktree内でチェックアウト済みのブランチ」
となります。
実際にディレクトリが作成されました。
「frontend-directory」をドラッグアンドドロップでVSCodeに持っていく
「backend-directory」をドラッグアンドドロップでIntelliJに持っていく
と、それぞれが独立した状態でブランチを切ったり、コードを書き換えることが出来るようになります。
.
├── backend-directory
│ ├── .idea
│ │ ├── .gitignore
│ │ ├── misc.xml
│ │ ├── modules.xml
│ │ ├── sample.iml
│ │ └── vcs.xml
│ ├── backend
│ │ └── index.js
│ └── frontend
│ └── index.html
├── frontend-directory
│ ├── .idea
│ │ ├── .gitignore
│ │ ├── misc.xml
│ │ ├── modules.xml
│ │ ├── sample.iml
│ │ └── vcs.xml
│ ├── backend
│ │ └── index.js
│ └── frontend
│ └── index.html
└── sample
├── .idea
│ ├── .gitignore
│ ├── misc.xml
│ ├── modules.xml
│ ├── sample.iml
│ ├── vcs.xml
│ └── workspace.xml
├── backend
│ └── index.js
└── frontend
└── index.html
💡 Worktree とモノレポ運用の線引き
「ローカルでバックエンドを書き換えながら、フロントも同時に動かす」
みたいなフルスタック開発は、モノレポ構成だと少しやりづらいです。
なぜなら、Worktree は“並行開発のための仕組み”であり、“統合環境を分割するツール”ではないからです。
💬 なぜ Worktree でフルスタック同時開発がやりづらいか
Worktree は ブランチ単位でファイルを分離 しているため、
同じリポジトリでも frontend_dev と backend_dev は物理的に別フォルダになります。
そのため「片方を修正 → もう片方が即反映」はできません。
（同じプロセスを共有していないため）
したがって、動作確認は統合環境（develop など）で行う
というのが自然なフローになります。
🧱 Worktreeとクローンの違い
結局やっていることは「複数の作業環境を同時に用意する」という意味では、
複数回クローンするのと大差ありません。
ただし決定的に違うのはここです👇
| 項目 | 通常の複数クローン | Worktree |
|---|---|---|
.git フォルダ |
各クローンごとに独立して存在 | すべてのワークツリーで共有 |
| 容量 | 重複が多くなる（履歴を都度複製） |
.git 共通化により大幅節約 |
| メリット | 独立性が高い | 同一リポジトリで効率的にブランチ切り替えが可能 |
「ほぼクローンと同じことをしているが、容量を節約しながら複数ブランチを同時展開できる」
というのが Worktree の本質です。
🧠 まとめ
Worktree は 「開発効率UPのための個人用分岐」
モノレポは 「統合管理のためのチーム基盤」
両方を組み合わせることで、
「個人の速度 × チームの整合性」 を両立できる開発構成になります