この記事の目次
- 1. 作業ツリーは、ファイルを編集する場所
- 2. ブランチ・worktree・cloneの違い
- 3. どんなときに使うと便利か
- 4. 別フォルダーにworktreeを作る
- 手順1：現在の状態と作業場所を確認する
- 手順2：新しいブランチと作業場所を追加する
- 手順3：追加したフォルダーへ移動する
- 5. 追加した場所でも、記録の手順は同じ
- 6. 並行作業で混同しやすいこと
- 同じブランチを、複数の場所で編集しない
- 履歴の共有と、編集内容の共有を分けて考える
- アプリの実行環境も確認する
- 7. 作業が終わったら、確認して片付ける
- 8. まとめと理解度確認
- 自分の言葉で説明してみる
- 解答例
- 参考資料
READMEを直している途中で、別の記事のリンク切れを修正したくなった。いまの作業をそのまま置いて、別のブランチを開いて作業できないだろうか。
そんな場面で役立つのが、Git worktreeです。この記事では、前回のブランチの記事に続いて、「履歴を分けること」と「作業する場所を分けること」の違いを学びます。
ここで扱うフォルダー名と修正内容は、説明のための練習例です。Git公式資料に基づいて、基本操作と片付け方まで整理します。
1. 作業ツリーは、ファイルを編集する場所
Gitで管理しているプロジェクトには、履歴を管理するリポジトリと、ファイルを開いて編集する作業ツリーがあります。
ブランチは開発の流れを表し、作業ツリーには選んだ状態のファイルが展開されます。通常の使い方では、1つのフォルダーでブランチを切り替えながら作業します。Git公式：用語集
worktreeを使うと、1つのリポジトリに作業ツリーを追加し、別のフォルダーで異なるブランチを同時に扱えます。Git公式：git worktree
たとえば、元のフォルダーではREADMEを修正し、追加したフォルダーではリンク切れを直す、といった使い方ができます。作業する場所を分けるので、どちらのファイルを編集しているかがわかりやすくなります。
2. ブランチ・worktree・cloneの違い
この3つは、目的が違います。
| 仕組み | 主な役割 | この記事での使い方 |
|---|---|---|
| ブランチ | 変更の履歴を分けて進める | README修正用の履歴に名前を付ける |
| worktree | 同じリポジトリに作業する場所を追加する | 別の修正用ブランチを別フォルダーで開く |
| clone | リポジトリを別の場所に複製する | プロジェクトを別のリポジトリとして取得する |
cloneは、新しいディレクトリーにリポジトリを作る操作です。ローカルからcloneする場合に内部データを共有する最適化が使われることはありますが、worktreeのように同じリポジトリへ作業ツリーを追加する操作とは異なります。Git公式：git clone
追加したworktreeは、コミットのデータや通常のブランチ参照を共有します。一方、作業中のファイル、ステージングエリア、現在の位置を示すHEADは、それぞれの作業場所に対応します。Git公式：リポジトリの構造
そのため、片方でREADMEを編集中でも、もう片方のREADMEが同時に書き換わるわけではありません。ただし、別々のバックアップが作られたわけでもありません。共通の履歴を使う、複数の作業場所です。 共有する履歴と、作業場所ごとの編集状態
同じリポジトリ：コミットのデータ・通常のブランチ参照を共有共通の履歴を使う
→元の作業場所
同じリポジトリ：コミットのデータ・通常のブランチ参照を共有共通の履歴を使う
→追加したworktree
元の作業場所この作業場所に対応
→元の作業場所のファイル・ステージングエリア・HEAD
追加したworktreeこの作業場所に対応
→追加した作業場所のファイル・ステージングエリア・HEAD
3. どんなときに使うと便利か
ここからは、記事原稿をGitで管理しているプロジェクトを想定します。
たとえば、作業を次のように分けられます。
| 作業フォルダー | 開くブランチ | 目的 |
|---|---|---|
notes | feature/readme-guide | READMEの説明を追加する |
notes-link-fix | fix/broken-link | 別の記事のリンク切れを直す |
元のフォルダーで編集途中の原稿を置いたまま、追加したフォルダーで修正を進められます。この例なら、急ぎのリンク修正のためにREADMEの作業を切り替える必要がありません。
ほかにも、変更前と変更後のソースを見比べる、別ブランチの動作を確認する、といった使い方が考えられます。
一方、1つの作業だけを順に進めるなら、ブランチの切り替えで十分なこともあります。worktreeを増やすほど、開いているフォルダーの確認や実行環境の準備も必要になるため、目的を決めて追加しましょう。
4. 別フォルダーにworktreeを作る
次の手順は、WindowsのPowerShellで、練習用のnotesフォルダーを開いている想定です。コミット済みのmainが存在し、fix/broken-linkと追加先のnotes-link-fixフォルダーはまだ存在しないものとします。mainは手元の状態を使い、リモートからの更新はこの例には含めません。
手順1：現在の状態と作業場所を確認する
git status
git worktree listgit statusでは、現在のフォルダーの変更を確認します。git worktree listでは、登録された作業場所とブランチを確認します。
手順2：新しいブランチと作業場所を追加する
git worktree add -b fix/broken-link ../notes-link-fix mainコマンドの各部分は、次の意味です。
| 指定 | 意味 |
|---|---|
git worktree add | 作業ツリーを追加する |
-b fix/broken-link | 新しいブランチを作る |
../notes-link-fix | 1つ上のフォルダーの下に追加先を作る |
main | このブランチのコミットを出発点にする |
すでに存在するブランチを使う場合は、-bを付けず、git worktree add ../notes-link-fix fix/broken-linkのように指定します。ただし、そのブランチがほかのworktreeで使用中なら、通常は追加を拒否されます。Git公式：worktreeの追加
手順3：追加したフォルダーへ移動する
cd ../notes-link-fix
git status移動後に、現在のブランチがfix/broken-linkになっていることを確認します。エディターも、この追加フォルダーを開いてください。元のフォルダーを開いたまま編集すると、別の作業を修正してしまいます。
5. 追加した場所でも、記録の手順は同じ
例として、追加フォルダーのarticles/sample.mdにあるリンクを修正し、保存したとします。
git diff
git add articles/sample.md
git diff --staged
git commit -m "記事のリンク切れを修正"
git statusworktreeでも、編集、差分確認、ステージング、コミットという順番は同じです。現在の作業場所にある変更を確認して記録します。git statusは、作業ツリーとステージングエリアなどの状態を表示します。Git公式：git status
この例でリンクの修正をコミットしても、元のフォルダーで進めているREADMEの未コミットの編集が、いっしょに記録されることはありません。
記録した修正をmainへ取り込むには、別途マージなどが必要です。worktreeの追加やコミットだけでは、mainの履歴は進みません。マージは、現在のブランチに別の履歴を取り込む操作です。Git公式：git merge
チームの共有ブランチへ反映する場合は、Pull Requestやレビューなど、そのチームの手順に従います。 追加した作業場所で修正を記録する流れ
- notesでgit status・git worktree listを確認状態と作業場所を確認して追加 ↓
- 手元のmainからfix/broken-linkとnotes-link-fixを作る追加先で作業を始める ↓
- 追加フォルダーへ移動し、ブランチを確認してエディターで開く対象ファイルを編集 ↓
- articles/sample.mdのリンクを修正・保存変更を確認 ↓
- git diffで差分を確認記録する変更を選ぶ ↓
- git add articles/sample.mdでステージングステージングした内容を確認 ↓
- git diff –stagedで記録する差分を確認確認した内容を記録 ↓
- git commitで修正を記録記録後の状態を確認 ↓
- git statusで状態を確認mainへ反映する場合 ↓
- mainへの取り込みには別途マージなどが必要
6. 並行作業で混同しやすいこと
同じブランチを、複数の場所で編集しない
通常、すでに別のworktreeで使われているブランチは、追加先で同時に使えません。別の目的には別のブランチを用意すると整理しやすくなります。拒否されたときは、強制する前にgit worktree listで使用場所を確認してください。
履歴の共有と、編集内容の共有を分けて考える
コミット済みのデータが共通でも、未コミットの編集は各フォルダーのファイルにあります。「もう片方でも見えるはず」と考えず、保存先と記録済みかどうかを確認しましょう。
アプリの実行環境も確認する
Gitが管理しない依存ライブラリーや設定ファイルなどは、追加フォルダーで別途準備が必要な場合があります。.gitignoreは未追跡のファイルをGitの管理対象から除外するための設定であり、それらを別の場所へ配布する仕組みではありません。Git公式：gitignore
また、フォルダーを分けても、同じポート番号、同じデータベース、同じ出力先を使うアプリ同士は干渉する可能性があります。並行起動する場合は、各プロジェクトの設定も確認してください。
7. 作業が終わったら、確認して片付ける
追加したworktreeを使い終えたら、まずそのフォルダーでgit statusを確認します。必要な修正はコミットし、未追跡ファイルやGitの管理対象外のファイルにも、残したいものがないか確認してください。
次の操作は、追加フォルダーを削除します。練習例では、元のnotesフォルダーへ戻って実行します。
cd ../notes
git worktree remove ../notes-link-fix
git worktree listremoveは追加worktreeを取り除く操作で、通常は変更や未追跡ファイルがあると拒否されます。--forceを安易に付けず、残っている内容を確認しましょう。Git公式：worktreeの削除
worktreeを取り除いても、対応するブランチは残ります。ブランチの削除は別の操作です。ブランチを残すかどうかは、変更を取り込んだか、まだ作業を続けるかで判断します。Git公式：git branch
なお、worktreeの移動にはgit worktree move、手動移動などで関連付けが壊れた場合にはgit worktree repairがあります。フォルダーだけを動かす前に、Gitの管理情報とのつながりを意識してください。 確認してworktreeを片付ける流れ
追加フォルダーでgit statusを確認削除前に内容を確認
→必要な修正をコミットし、未追跡・管理対象外にも残したいファイルがないか確認
必要な修正をコミットし、未追跡・管理対象外にも残したいファイルがないか確認必要な内容を確認して戻る
→cd ../notesで元のフォルダーへ戻る
cd ../notesで元のフォルダーへ戻る元のフォルダーで実行
→git worktree remove ../notes-link-fixを実行
git worktree remove ../notes-link-fixを実行変更や未追跡ファイルなどで拒否された場合
→拒否されたら残っている内容を確認し、–forceを安易に付けない
git worktree remove ../notes-link-fixを実行取り除いた後に確認
→git worktree listで作業場所を確認
git worktree listで作業場所を確認worktreeの削除とブランチの削除は別
→対応するブランチは残る
対応するブランチは残るブランチの扱いを判断
→取り込み済みか・作業を続けるかで、ブランチを残すか判断
8. まとめと理解度確認
ブランチは変更の履歴を分け、worktreeは作業する場所を増やします。別フォルダーで並行して作業できるようになりますが、どの場所で何を編集しているかの確認は必要です。
この記事の練習例を整理すると、次の流れになります。
- 元のフォルダーで、状態とworktreeの一覧を確認する。
- mainを出発点に、リンク修正用ブランチと追加フォルダーを作る。
- 追加フォルダーを開き、修正とコミットを行う。
- 必要な内容が記録されているか確認し、使い終えたworktreeを取り除く。
自分の言葉で説明してみる
- ブランチとworktreeは、何を分ける仕組みですか？
git worktree add -b fix/broken-link ../notes-link-fix mainの最後のmainは何を指定していますか？- 元のフォルダーの未コミットの編集は、追加worktreeでのコミットに自動で含まれますか？
- 追加worktreeを削除するとき、先に何を確認しますか？
- worktreeを取り除くと、ブランチも同時に削除されますか？
解答例
- ブランチは変更の履歴を分け、worktreeは作業する場所を増やします。
- 新しいブランチと作業ツリーを作る出発点です。この例では手元のmainのコミットを使います。
- 含まれません。未コミットの編集とステージングエリアは、それぞれの作業場所で確認します。
- 対象のフォルダー、未コミットの変更、未追跡ファイル、管理対象外でも残したいファイルを確認します。
- 削除されません。ブランチの削除は別の操作です。
参考資料
- Git公式：git worktree
- Git公式：用語集
- Git公式：リポジトリの構造
- Git公式：git clone
- Git公式：git status
- Git公式：git merge
- Git公式：gitignore
- Git公式：git branch
資料確認日：2026年10月11日
コメント