💥 pnpm create をリポジトリ直下で叩いて.gitを消した話(#0006)

💥 pnpm create をリポジトリ直下で叩いて.gitを消した話

pnpm create や npm create のようなテンプレート生成コマンドは、空のディレクトリで実行するもの——知識として知っていても、既存リポジトリの直下で叩いてしまう瞬間があります。この記事は、実際にそれをやって作業ツリーと .git をまとめて失い、そこから復旧するまでの記録と、二度とやらないために手順をどう変えたかです。

筆者は「Trueful」という開発者向けのOSSブラウザを個人で作っています。#0000〜#0005で思想・Design System・技術選定・AI設計・ロードマップという設計編を一通り書き終え、#0006にあたる今回から実装編に入りました。その初日、コードを1行も書かないうちに起きた事故です。

何が起きたか

Electron + React + TypeScript の開発環境を作るため、Electronのテンプレート生成コマンドを実行しました。

pnpm create @quick-start/electron@latest .

コマンド自体は正常終了しました。問題はその後です。

• docs-ja/ docs-en/ assets/ README.md LICENSE が見当たらない
• 代わりに src/ electron.vite.config.ts package.json など、Electronテンプレート一式が展開されている
• git status を叩くと fatal: not a git repository (or any of the parent directories): .git

最後の1行が効きました。ディレクトリの中身が置き換わっただけなら戻しようもありますが、.git が無いということは、Gitで戻す手段そのものが無いという意味です。

最初に疑ったこと（と、それが外れた理由）

焦っている間に3つほど的外れな仮説を立てたので、そのまま書いておきます。同じ症状で同じ勘違いをする人がいるはずなので。

「上書き確認を出さないのはコマンド側の不具合では」

違いました。pnpmの公式ドキュメントには pnpm create が「create-* / @foo/create-* のスターターキットからプロジェクトを作成する」コマンドだと書かれています。展開先に何があるかを守る責任はテンプレート側の実装に委ねられていて、コマンドの契約として既存ファイルの保護が約束されているわけではありません。. を渡した時点で「ここに展開してよい」と伝えたことになります。仕様通りの動作に、自分が驚いただけでした。

「git checkout . で戻せるのでは」

戻せません。git checkout も git restore も git reflog も、.git ディレクトリの中身を読んで動きます。その .git が消えている以上、Gitのコマンドは全滅です。「Gitで管理しているから安全」という感覚が、どの範囲まで有効なのかを取り違えていました。

「ゴミ箱に残っているのでは」

残っていませんでした。Finderからの削除ではなく、プロセスがファイルシステムを直接書き換えた結果なので、ゴミ箱を経由していません。

この3つが外れた時点で、ローカルには手掛かりが1つも残っていないことが確定しました。

本当の原因

原因を掘っていくと、3層に分かれていました。

表層と中層は誰でも思いつく反省ですが、本当の原因は深層です。もし先に「Electronアプリは app/ 以下に置く」と決めていたら、コマンドに . を渡す理由がそもそも存在しませんでした。mkdir app && cd app してから実行していたはずです。

つまりこれは、うっかりミスというより配置を決める前に生成コマンドを打ったという順序の事故でした。この整理ができたことが、今回いちばんの収穫だったと思っています。

どう直したか

幸い、TruefulのリポジトリはGitHub上に残っていました。ここが唯一の生存点です。

1. 壊れたディレクトリを別名にリネームして退避（この時点では消さない）
2. GitHubからリポジトリを再clone
3. app/ ディレクトリを作り、その中でテンプレートを生成
4. 退避したディレクトリを見て、拾うべき未pushの変更が無いことを確認してから破棄

失ったのは「その日のローカル作業」だけで、push済みのドキュメントは全部戻ってきました。手順3で階層を1つ切ったことで、リポジトリはこうなりました。

Trueful/
├── app/        # Electronアプリ本体
├── docs-ja/    # 日本語ドキュメント
├── docs-en/    # 英語ドキュメント
├── assets/
├── README.md
└── LICENSE

事故前はドキュメントとコードがリポジトリ直下で混在していたので、結果的には整理された構成になりました。ただしこれは事故によって整理されたのであって、設計して到達したわけではありません。そこは正直に書いておきます。

復旧後の環境は次の通りです。

アプリ部分は electron-vite で構築しました。Electron向けの構成が最初から用意されていること、Viteによる開発時のリロードが速いこと、React + TypeScript との組み合わせが素直に通ることが理由です。Node.jsは nvm 管理下に置いています。今回の事故とは直接関係ありませんが、別プロジェクトとバージョンが食い違ったときに、リポジトリを触らず切り替えられる状態にしておきたかったためです。

同じことを起こさないために

「気をつける」で終わらせると再発するので、手順として書き換えました。

• create 系コマンドに . を渡さない。 必ず mkdir <name> && cd <name> してから実行する。展開先を引数ではなくカレントディレクトリの移動で表現すれば、「ここに何があるか」を見る動作が手順に組み込まれる
• 実行直前に pwd と ls -a を見る。 .git が見えるディレクトリで生成コマンドを叩かない、という判定にする
• 作業を始める前にpushする。 「リモートが唯一の生存点」なら、その生存点を新鮮にしておくのが最も安いバックアップになる
• 配置を先に決める。 生成コマンドは配置が決まった後の作業であって、配置を決めるための作業ではない

4つ目だけ性質が違います。前の3つは事故を防ぐ策ですが、4つ目は事故が起きる状況を作らない策です。

復旧できたのは「失敗前提の設計」を先に決めていたから

Truefulの思想編（#0001）で、Layer 2（Technical Freedom）の原則のひとつとして Failure Friendly を掲げていました。失敗が起きないようにするのではなく、失敗したときに戻れるように設計しておく、という原則です。ブラウザの設計方針として決めたつもりのものでした。

今回、それが自分自身の開発フローにそのまま当てはまりました。復旧できた理由を分解すると、「リモートに正本がある」「ローカルは捨てられる」「復旧手順が4ステップで書ける」——これは Failure Friendly をブラウザに実装しようとしていた内容と同じ構造です。

思想を先に固めておくと、その思想が自分の作業にも跳ね返ってくる。設計編に5本も費やしたことの、意図していなかった副産物でした。

総括

事故そのものは、初日にやりがちな部類のミスです。ただ、そこから引き出せたものは2つありました。

1つは、復旧できるかどうかは事故が起きた後ではなく前に決まっているということ。GitHubにpushしてあったから戻れたのであって、当日の判断が良かったわけではありません。防御は事前にしか置けません。

もう1つは、うっかりミスに見えるものの多くは順序のミスだということ。「配置を決める前に生成した」が根っこで、. を渡したのはその結果に過ぎませんでした。再発防止を「注意する」に置くと表層しか直りませんが、順序に置けば構造ごと直ります。

まだブラウザの機能は1つもありません。それでも、今日からTruefulは「構想」ではなく「動くプロジェクト」になりました。

次回

#0007（Workspace管理の設計編）では、MVPの最優先機能であるWorkspace管理の設計に入ります。コードを1行も書かないまま、設計を6回ひっくり返した1日の記録です。

GitHub

開発環境構築の詳細手順（Developer Handbook 第1章）はこちら。

AIの利用について