タイムラインビューの深淵：Gitの網の目を抜けたコードを救い出すローカルヒストリーの低レイヤアーキテクチャ
こんにちは、DevOpsアーキテクトの私だ。
日夜、CI/CDパイプラインの最適化や、ゼロ・コンテキストで秒速起動する開発環境の構築に心血を注いでいるあなたなら、一度は経験があるはずだ。
「あれ、この関数、さっきまで動いていたのに……」
「ブランチを切り替える前に、一時的に殴り書きしたコードが消えた……」
「そもそも、この設定ファイルはまだGitでトラッキング（`git add`）すらしていなかった……」
慌てて `git reflog` を叩いても、コミットされていない変更の残骸など影も形もない。絶望的な静寂の中、Ctrl+Z（Cmd+Z）を連打してエディタのUndoバッファの神様に祈る――。
エンジニアとしてあまりに不毛で、精神衛生上最悪な時間だ。
世間の大半の開発者は、「VS Codeのタイムライン（Timeline）ビュー＝GitのコミットログをGUIで綺麗に見せるだけのオマケ機能」だと思い込んでいる。しかし、それはこの機能のポテンシャルの1%すら見えていない。
VS Codeの内部には、Gitリポジトリの有無やステージングの状態を完全に超越したローカルヒストリー（Local History）エンジンが静かに稼働している。本稿では、このローカルヒストリーの内部構造を剥ぎ取り、いかにして「Git管理外のファイルや削除されたコードの完全な安全網」として昇華させるか、その設計思想と実践知を極限まで解説する。
—
1. ローカルヒストリーの内部アーキテクチャ：VS Codeはどこで何を記録しているのか？
まず、この機能がどのようなメカニズムで動いているのかを理解しなければならない。魔法のように過去のコードが蘇るわけではない。VS Code（正確にはその基盤であるElectron/Node.jsランタイム）は、ファイルシステム上で巧妙なデータ管理を行っている。
ストレージの物理実体
VS Codeのローカルヒストリーは、Gitのオブジェクトデータベースとは完全に独立して、OSごとのユーザーデータディレクトリ（User Data Directory）の配下に格納されている。
- macOS: `~/Library/Application Support/Code/User/History/`
- Linux: `~/.config/Code/User/History/`
- Windows: `%APPDATA%\Code\User\History\`
このディレクトリを覗いたことがあるだろうか？ 中に入ると、ハッシュ値のようなランダムな英数字のディレクトリが並び、その中にさらにハッシュ名のファイルが散らばっている。
~/.config/Code/User/History/
┣ 5a3f2b1c/
┃ ┣ entries.json <-- 変更履歴のメタデータインデックス
┃ ┣ h1a2b3c4.ts <-- スナップショット1
┃ ┗ f8e7d6c5.ts <-- スナップショット2
┗ ...
データのライフサイクルとトリガー
VS Codeでファイルが「保存（Save）」されるたびに、以下のプロセスがバックグラウンドで非同期実行される。
1. 差分検知: 前回保存時のスナップショットと、現在のバッファ内容を比較。
2. スナップショット生成: 変更が検定された場合、内部ストレージへファイルの実体をバイナリ/テキストとしてコピー保存。
3. メタデータ更新: `entries.json` にタイムスタンプとファイルパス、対応するスナップショットのハッシュを追記。
つまり、Gitでコミットしていようがしていなかろうが、「こまめに `Ctrl+S`（`Cmd+S`）を押す」という開発の基本動作そのものが、ローカルヒストリーへの強力なバックアップ・トランザクションとして機能しているのだ。
—
2. タイムラインビューの真価：Gitヒストリーとの融合と「ローカルファイル」の救出
タイムラインビューは、エディタのエクスプローラー下部（デフォルト）にひっそりと鎮座している。ここには、以下のプロバイダー（情報源）がマージされて時系列で表示される。
- Git: コミット、変更（Modified）、ステージング状態
- File History: VS Codeが独自に保存したローカルスナップショット
- FileSystem: 外部プロセスによるファイルの変更検知
現場で即座に使える「未管理ファイル」の復旧シナリオ
例えば、新規に `docker-compose.override.yml` を作成し、複雑なネットワーク設定や環境変数を流し込んでいたとする。まだGitには追加していない。
その状態で、誤ってファイルの内容をすべて消去し、さらに上書き保存（`Cmd+S`）してしまったとしよう。
Gitは当然「そんなファイルは知らない（Untracked）」ので助けてくれない。しかし、タイムラインビューを開けば、そこには「File History」というカテゴリで、数分おきに保存されたスナップショットのリストが美しく並んでいる。
1. 該当ファイルをエディターで開く。
2. タイムラインビューから、消去される直前のタイムスタンプを選択する。
3. Diff（差分）ビューが即座に起動し、失われたコードがハイライト表示される。
4. 「Restore（復元）」ボタンを押すか、必要な部分だけをコピーして現在のエディタへ持ってくる。
この一連の動作に、ネットワーク接続も、リモートリポジトリへのプッシュも一切不要である。完全なオフライン環境、かつGitの初期化すらしていないサンドボックスであっても、このタイムガードは機能し続ける。
—
3. 生産性を極限まで高める：ローカルヒストリーの高度なカスタマイズ
デフォルトの設定のままでも強力だが、大容量のログファイルやビルド成果物までローカルヒストリーに記録されてしまうと、ストレージが圧迫され、エディタ全体のパフォーマンス（ファイル監視のオーバーヘッド）に悪影響を及ぼす。
真のエンジニアであれば、この振る舞いを完全に制御下置くべきだ。`settings.json` に以下の極限チューニングを施せ。
{
// ==========================================
// ローカルヒストリー（Timeline / History）の高度な最適化設定
// ==========================================
// ローカルヒストリー機能を有効化（デフォルトでtrueだが明示的に担保）
“workbench.localHistory.enabled”: true,
// 1つのファイルあたりに保持する最大エントリ数（デフォルトは50）
// 大規模なリファクタリングを頻繁に行う場合は100〜200に引き上げるが、
// ストレージ消費量とのトレードオフを考慮する
“workbench.localHistory.maxFileSize”: 1024, // KB単位。1MBを超える巨大ファイルは履歴対象外にする
// ローカルヒストリーの保持期間（日単位）。無制限にすると数ヶ月で数GBに膨らむため、
// 開発サイクルの1スプリントに合わせて30日程度に制限をかけるのがアーキテクトの知見
“workbench.localHistory.expiration”: 30,
// 除外するパターン（バイナリ、自動生成される一時ファイル、巨大なJSONなどを除外し、
// I/Oの無駄な負荷とディスク肥大化を防ぐ）
“workbench.localHistory.exclude”: {
“/node_modules/“: true,
“/.git/“: true,
“/dist/“: true,
“/build/“: true,
“/.log”: true,
“/.lock”: true,
“/tmp/“: true,
“/.DS_Store”: true
},
// タイムラインビューに表示する最大アイテム数
“timeline.maxEntries”: 150
}
なぜこの設定が必要なのか？（アーキテクトの洞察）
Node.js環境やDockerボリュームをマウントしたコンテナ内開発において、`node_modules` やビルド成果物がローカルヒストリーの監視対象に入ってしまうと、ファイル保存のたびにVS Codeのメインスレッドやファイルウォッチャー（Chokidar等）に過大な負荷がかかる。結果として、入力遅延（Input Latency）やCPU使用率のスパイクを引き起こす。
上記の `exclude` 設定は、エディタのパフォーマンスを守るための防壁なのだ。
—
4. CI/CDやDocker環境における「ヒストリーの限界」と割り切り
ここで、DevOpsの観点から重要な注意点を述べておく。
VS Codeのローカルヒストリーは、あくまで「ローカルのクライアント環境（あなたの手元のマシンやDev Container）」に閉じた機能である。
GitHub ActionsやGitLab CIなどのCI/CDパイプライン上で実行されるビルドやテスト、あるいはEphemeral（使い捨て）なDockerコンテナ内で作業している場合、コンテナが破棄されるとローカルヒストリーのストレージ（`~/.config/Code/User/History/`）も一緒に消え去る。
Dev Containerでの永続化ハック
もしDockerのDev Containers環境でこのローカルヒストリーの恩恵をフルに受けたい（あるいはコンテナを再ビルドしても履歴を保持したい）場合は、VS Codeのユーザーデータ自体をボリュームマウントでホスト側に逃がすか、あるいは開発コンテナの機能拡張設定で永続化ストレージに結びつける設計が必要となる。
しかし、そもそもコンテナ内での一時的なコードの消失を防ぐためには、タイムラインビュー頼みではなく、適切なタイミングでの `git commit` や、WIP（Work in Progress）ブランチへのこまめなプッシュ、あるいはStashの活用が本来のDevOpsプラクティスである。
ローカルヒストリーは、「Gitのコミットボタンを押す前の、ほんの数秒〜数分のセーフティネット」として位置づけるのが、最も美しく、破綻のない運用哲学だ。
—
5. まとめ：エディタを信頼し、コードの迷子をゼロへ
私たちは日々、複雑化するコードベースと格闘している。
「動いていたはずのコードが動かない」という恐怖から解放されるだけで、エンジニアの認知負荷（Cognitive Load）は劇的に軽減され、より本質的なアーキテクチャ設計やアルゴリズムの思考に脳のメモリを割くことができる。
タイムラインビューとローカルヒストリー機能は、地味で派手さのない機能かもしれない。しかし、その内部構造と設定の裏側を完全に把握し、自らの開発スタイルに最適化した者にとって、それは最強の「不可逆的ミスを防ぐ盾」となる。
明日から、いや、今この瞬間から、焦って `Ctrl+Z` を乱れ撃つのはやめにしよう。タイムラインビューを開き、VS Codeがあなたのために静かに積み上げてきた「時間の足跡」を信頼するのだ。
あなたのコードが、二度と闇に消え去らないことを願う。