「ブランチを変更してしまったかもしれない」
AIツールの画面に見慣れない表示が出た瞬間、そんな焦りが走った。ブランチ？ 何それ。壊した？ 消えた？──そこから、GitHubとの思いがけない格闘が始まった。
きっかけは「よく分からないまま触っていた」こと
AIコーディングツールを使って作業をしていたとき、気づかないうちに「ブランチ」を変更してしまったらしかった。
ブランチとは何か。その時点ではよく分かっていなかった。とにかく「何かを変えてしまった」という不安だけがあった。
こういうとき、知識のないまま焦って操作するのが一番危ない。そこで一度立ち止まり、まずGitとGitHubの基本をちゃんと理解してから動こうと決めた。
まずテスト用の「練習場」を作った
本番で使っている作業フォルダをいきなり触るのは怖い。そこで最初にやったのは、何も入っていない使い捨てのリポジトリを作って、そこで基本操作を体験することだった。
「リポジトリ」というのは、ひとことで言えばGitHubが管理するフォルダのことだ。ファイルの変更履歴もまとめて保存できる。
この練習用リポジトリで、次のことをひととおり試した。
- ファイルを作って保存する（コミット）
- GitHubに反映させる（プッシュ）
- 作業の分岐を作る（ブランチ）
- 分岐した変更を本流に取り込む提案をする（プルリクエスト）
- 実際に取り込む（マージ）
- 不要になった分岐を消す（ブランチ削除）
やってみて初めて、頭で分かるのと体で分かるのは全然違うと実感した。
理解できたのは、こういうことだ。
- main（メイン）= 本流。正式版を置いておく場所
- ブランチ= 本流を汚さずに試せる「別作業台」
- コミット= ローカルへの保存。「ここまでは大丈夫」という記録点
- プッシュ= そのコミットをGitHubに送ること
- プルリクエスト（PR）= 「この変更をmainに入れていいですか」という提案
- マージ= 提案を受け入れて、本流に取り込むこと
この感覚が、操作を通じてようやくつかめた。
本番フォルダに目を向けたら、問題が見えてきた
基本を理解したところで、次は本番の作業フォルダをGitHubでバックアップできる状態にしようと試みた。
ところが、いざ中身を確認してみると、そのまま丸ごとGitHubに上げるのは危険だと分かった。
フォルダの中には、気づかないうちにこんなものが混ざっていた。
- ブラウザのプロフィールデータ（ログイン情報・履歴・Cookieを含む）
- キャッシュファイル
- ローカル専用の設定ファイル
tmp_から始まる一時ファイル群
GitHubは基本的にインターネット上にファイルを保存するサービスだ。「プライベートリポジトリ」なら非公開にはなるが、それでもログイン情報などの機微なデータが混入するのは避けたい。
まず安全を確保してから、バックアップを考えるという順番が大事だと気づいた。
ClaudeとCodexで役割を分けた
ここで活用したのが、AIツールの役割分担だ。
- Claude → フォルダ構成や危険なファイルの傾向を調査・分類する役
- Codex → 指定された範囲だけを小さく安全に処理する役
ClaudeはCodexに比べて、説明や判断が得意だ。「このファイルは何のために存在するか」「GitHubに出してはいけないものはどれか」を整理するのに向いている。
一方、Codexは「このファイルだけをgit管理対象から外す」「この範囲だけ削除する」といった、小さく限定された実行作業に強い。
調査と判断はClaude、実行はCodex。この分業がうまく機能した。
ここで大事だったのは、「危険なファイルを消す」のではなく、「GitHubに出さない状態を作る」ことだった。
「削除」ではなく「追跡解除」という考え方
ここで学んだ重要な概念がある。
Gitには「追跡」という概念がある。一度Gitに登録されたファイルは、その後削除しても「削除されたこと自体が履歴に残る」。逆に言えば、ファイルをローカルに残しながら、「GitHubには出さない」という状態を作ることもできる。
具体的には、
.gitignore（ギットイグノア）というファイルを作る
「このパターンのファイルはGitで管理しない」というルールを書いておくファイルだ。- すでに追跡されているファイルは「追跡解除」する
git rm --cachedという操作で、「ローカルには残すが、Gitの管理対象からは外す」ことができる。
こうして、ブラウザプロフィール・キャッシュ・一時ファイルなどを、ローカルには残しながらGitHubには出さない状態に整えた。
実ファイルを消すのではなく、管理対象から外す。この発想の転換が、安全な整理の鍵だった。
「deleted 300件超」という想定外の課題
整理を進める中で、もう一つ気になることが出てきた。
Gitの状態を確認すると、「deleted（削除済み）」として記録されているファイルが300件以上あった。
最初は「これは全部消していいのでは」と思ったが、実際には単純ではなかった。
内訳を丁寧に見ていくと、3種類のファイルが混在していた。
- 手作業で削除した不要ファイル──これは削除確定してよい
- 実は別フォルダに移動しただけのファイル──Git上では「deleted」に見えるが、実際には移動しただけだった
- まだ削除を確定すべきでない草稿や完成稿──迂闊に消せない
たとえば、PowerPoint由来の画像ファイルは比較的安全に削除確定できた。しかし、記事の草稿・SEO関連ファイル・運用メモなどは、「deleted」に見えていても安易に消すべきではないと判断された。「移動しただけ」のファイルをうっかり削除確定してしまえば、必要なものを失うことになる。
Git管理で本当に大事なのは、容量よりも判断だと実感した瞬間だった。
clean な「main」をGitHubに公開できた
ここまで整理した後、いよいよGitHubへの公開に取り組んだ。
ただし、整理途中の状態で雑にpushするのは危険だ。そこで、
- 作業途中の変更を一時退避（スタッシュ）
- 問題のないクリーンな状態を作る
- その状態を基準として
mainブランチを新規作成 - GitHubの非公開（Private）リポジトリにpublish
という手順を踏んだ。
「スタッシュ」とは、コミットするほどではないが一時的に保存しておきたい変更を、作業台の「引き出し」に仮置きするようなイメージだ。
この手順を経て、ようやく
- ローカルの作業フォルダ
- GitHubのPrivateリポジトリ
- 安全な基準点としてのmainブランチ
が、はじめてつながった。
今日一番よく分かったこと
一日を振り返って、最も印象に残ったのは次の考え方だ。
「削除より、まず移動」「一括処理より、小分け」
Gitを使うと、ファイルを削除することより「何をどこに置いて、何をGitHubに出すか」を考えることの方がずっと大事だと分かる。
一気に整理しようとすると判断を誤る。小さく限定して、確認しながら進める。この姿勢が、AIツールと一緒に作業するときにも同じく有効だった。
まだ「削除済み」ファイルの残件整理など、宿題は残っている。だが、少なくとも今後の基準点となる安全なmainをGitHubに確保できた。
GitHubは単なるクラウド保存先ではなく、「何を残すべきか」を問い続けるための仕組みでもある──そう思えた一日だった。
本記事は実際の作業体験をもとに整理したものです。GitやGitHubの操作は環境によって表示や手順が異なる場合があります。
