working treeとは?作業中のファイル置き場

working tree(ワーキングツリー)って何?

Gitを使っていると、ドキュメントやエラーメッセージで「working tree」という言葉がやたら出てきます。日本語だと「作業ツリー」「作業ディレクトリ」などと訳されますが、要するにいま自分が実際に編集しているファイルたちが置かれている場所のことです。

プロジェクトのフォルダを開いたときに見える src/ や README.md といったファイル群、あれがそのまま working tree です。特別な場所ではなく、ふだんエディタで開いているあのファイルそのもの、と思ってもらって構いません。

図書館の例え

Gitを図書館だとすると、過去のコミット(履歴)は書庫に保管された蔵書です。一度収められた本の中身は勝手に変わりません。一方 working tree はあなたが机の上に広げている本とノートにあたります。線を引いたり書き込んだりできるのは机の上の方だけで、書庫の蔵書はそのまま。机の上で加えた変更を「これで確定」として書庫に収める作業が、コミットです。

だから「working tree が汚れている(dirty)」という言い方は、机の上に書きかけのメモが散らかっている状態、つまりまだコミットしていない変更が残っているという意味になります。

コミット済みの状態と何が違うのか

Gitは大きく分けて3つの場所を意識すると理解しやすくなります。

ファイルを書き換えると、まず working tree だけが変わります。git add するとステージに載り、git commit で初めて履歴として記録されます。git status を打ったときに出てくる「Changes not staged for commit」は、working tree にだけ変更がある状態を指しています。

場所	中身	編集できる?
working tree	いま開いているファイル	できる
ステージ	次のコミットに含める予定の変更	直接は編集しない
コミット履歴	過去に確定した状態	書き換えない(やり直しは別操作)

Claude Codeとどう関係するのか

Claude Code はターミナルからプロジェクトのファイルを読み書きするツールなので、AIが編集した結果はまず working tree に反映されます。つまりAIが書いたコードも、最初はあなたの机の上に置かれた下書きにすぎないということです。

ここが実は安心材料でもあります。AIがファイルを変更しても、コミットしていない限り履歴は汚れません。納得できなければ変更を破棄すればいいし、気に入ったところだけコミットすることもできます。逆に言うと、AIに作業を任せる前に、自分の変更をコミットしておくのが鉄則です。机の上がきれいな状態から始めれば、「どこまでが自分の変更で、どこからがAIの変更か」が git diff ひとつで一目瞭然になります。

最初につまずきやすいところ

自分も最初そうだったのですが、「変更を保存した=Gitに記録された」と勘違いしがちです。エディタで Ctrl+S を押して保存しても、それは working tree のファイルが書き換わっただけ。Gitの履歴にはまだ何も残っていません。PCが壊れたりファイルを消したりすれば、その変更は消えます。

もうひとつは、working tree に変更を残したままブランチを切り替えようとして怒られるパターン。机の上に書きかけの資料を広げたまま別の仕事に移ろうとすると、どっちの資料か分からなくなる——Gitはそれを防ぐために止めてくれているわけです。

覚えておきたい最小限

専門用語としては難しく聞こえますが、やっていることは単純です。working tree = いま触っているファイルの現物。そしてそこに加えた変更は、コミットするまでGitの履歴には入らない。この2点さえ押さえておけば、git status の出力もエラーメッセージも、だいぶ読めるようになります。