女性向けエンジニアスクール
3秒でわかる
Gitで実際にファイルを編集している作業フォルダのこと。ここでの変更はまだ記録されておらず、addとcommitを経て履歴になります。
もう少し詳しく
どういうものか
ワーキングツリーは、エディタで開いて実際に編集しているファイル群そのものです。Gitはひとつのリポジトリを3つの領域に分けて扱っており、その入口にあたります。
ワーキングツリー → <a href="/glossary/stage" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">ステージ</a>(<a href="/glossary/index-db" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">インデックス</a>) → リポジトリ
編集中の実体 git add で載せた分 git commit で確定した履歴git status を実行したとき、Changes not staged for commit に並ぶのがワーキングツリーだけにある変更、Changes to be committed に並ぶのがステージへ載せた変更です。
なぜ必要か
編集と記録を分けるためです。ファイルを保存するたびに履歴が増えると、書きかけの状態や実験のための書き換えまで全部が残り、後から読める履歴になりません。ワーキングツリーは自由に壊せる場所として用意されており、そこから「これは残す」と選んだ分だけをステージに載せ、意味のあるまとまりでコミットします。
ひとつのファイルの中でも、git add -p を使えば部分ごとに選んで載せられます。バグ修正と整形の変更が混ざってしまったときに、修正だけを先にコミットできるのはこの構造のおかげです。
具体例
# 3つの領域の状態をまとめて確認する
git status
# ワーキングツリーとステージの差分(まだ add していない分)
git diff
# ステージと直前のコミットの差分(add 済みの分)
git diff --staged
# ワーキングツリーの変更を捨てて、最後にコミットした内容へ戻す
git restore path/to/file.js
# ステージから降ろす(編集内容は消えない)
git restore --staged path/to/file.jsgit restore はワーキングツリーの変更を消す操作で、Gitの履歴に残っていない内容は元に戻せません。実行前に git diff で捨てる中身を確認します。
つまずきやすいところ
git add を「保存」だと思い込む誤解が最初の関門です。add はステージへ載せるだけで、履歴にはまだ入っていません。add した後にもう一度そのファイルを編集すると、編集分はワーキングツリーに残り、そのままコミットしても新しい編集は含まれません。add してから直したら、もう一度 add します。
ブランチを切り替えるとき、ワーキングツリーに未コミットの変更が残っていると切り替えが拒否されることがあります。区切りが悪くて commit したくないときは git stash で一時的に退避させ、戻ってきてから git stash pop で復元します。
似た用語との違い
| 領域 | 中身 | 確認するコマンド |
|---|---|---|
| ワーキングツリー | 今エディタで見えているファイル | git diff |
| ステージ | 次のコミットに含める予定の変更 | git diff --staged |
| リポジトリ | 確定した履歴 | git log |
