Gitのことを、わかってるようでわかってなかった

ロボットを動かす合間に、ずっと後回しにしてきたGitを本気で理解した日。

💡 Key Takeaway

「コミットしていたから戻れた」だけで使ってきたGitを、今日初めて構造から理解した。.gitignoreを4つのリポジトリに設定しながら、教科書どおりのコンフリクトまでリアルに体験した。知ってるつもりで使えてなかったものを、使えるものにする。

GitとGitHubは、別物だった

— 「なんとなく使ってるけど腑に落ちていない」状態を終わらせた。

ずっと後回しにしてきたことがあった。Gitだ。

LOG83でAIスクリプトがデータを破壊したとき、git cloneで即座に復元できた。あの体験でGitの価値はわかった。コミットしておけば戻れる、それだけは骨身に沁みた。でもその先——ブランチがなんのためにあるのか、コンフリクトが起きたらどう対処するのか——は、ずっと「なんとなく」のままだった。

改めて基礎から整理した。

まず最初に整理すべきは「GitとGitHubは別物」という事実だ。

Git     ファイルの差分（変更履歴）を管理するシステム。自分のPC上で動く。
GitHub  Gitリポジトリをクラウド上に置いて共有できるサービス。

「セーブデータの管理システム」がGitで、「そのセーブデータをネット上に置いて他の人と共有できる場所」がGitHubだ。両者は独立しており、Gitがなければ、GitHubは成立しない。

Gitが管理しているのは「ファイルの差分」だ。

最初 → 「こんにちは」
変更 → 「こんにちは世界」  ← この差分を記録
変更 → 「Hello World」    ← この差分を記録

だからどの時点にも巻き戻せるし、誰がいつ何を変えたかが追える。LOG83のあの状況は、まさにこの仕組みが機能した瞬間だったのだと、今日改めて理解した。

.gitignoreが最重要タスクだった

— 今すぐやるべきだったことに、今日気づいた。

概念を整理した後、すぐに「今すぐやるべきこと」が明確になった。

.gitignoreだ。

「Gitで追跡しなくていいファイルのリスト」を書いたテキストファイルで、プロジェクトのルートに置く。これがないと何が起きるか。

❌ APIキーが書かれた .env ファイルをGitHubに公開してしまう
❌ 1GB超えのUnityキャッシュをコミットしてリポジトリが重くなる
❌ MacのDS_Storeファイルが大量にコミットされてノイズになる

Robotics_UXリポジトリには.gitignoreが存在していなかった。確認したところ、Libraryフォルダ（数百MB〜GB級のキャッシュ）がコミットされ続けるリスクがあることが判明した。

幸い、今の時点でLibraryフォルダが実際にはgit管理下になかったことが確認できた。被害ゼロで気づけた。

4つのリポジトリを一気に整備した。

Robotics_UX用の.gitignoreはUnityとPythonの複合プロジェクトなので、両方のルールを合体させた構成にした。

# Unity
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/

# Python
__pycache__/
*.py[cod]
.env
.venv/

# macOS
.DS_Store
.AppleDouble

「プロジェクト開始時の儀式」として.gitignoreを真っ先に設定する、という習慣の大切さを、今ようやく実感した。

コンフリクトを、教科書どおりに体験した

— 知識として知っていた「コンフリクト」が、現実の問題として目の前に現れた。

r2r2r-contentに.gitignoreを追加してpushしようとしたとき、こんなエラーが出た。

! [rejected] main -> main (fetch first)

GitHub側に変更が先にあるため、「pullしてから pushして」と言われている状態だ。

これが「コンフリクト」だった。

GitHub側：A → B → C（自分が知らない変更がある）
ローカル ：A → B → [.gitignoreのコミット]

--rebase をつけることで「GitHub側の変更を先に受け取って、その上に自分のコミットを乗せる」という処理になる。

試行錯誤の結果、最終的には git reset --hard origin/main でGitHub側の.gitignoreを正として受け入れ、その上にPythonの設定だけ追記してpushするアプローチで解決した。

# 全部リセットしてGitHub側に合わせる
git merge --abort
git fetch origin
git reset --hard origin/main

# Python関連だけ追記
cat >> .gitignore << 'EOF'
# Python
__pycache__/
*.py[cod]
.env
.venv/
EOF

git add .gitignore
git commit -m "Add Python rules to .gitignore"
git push

コンフリクト → rebase → merge → reset --hard、という一連の操作を1日で全部体験した。 教科書で読んでいた概念が、ターミナルの実際のエラーとして現れて、コマンドで解決された。

ブランチは「壊す可能性がある作業のとき」に切る

— 習慣にすべきことが、明確になった。

整理した中で、もう一つ腑に落ちたことがある。ブランチをいつ切るかだ。

現場での判断基準はシンプルだった。

「動いているものを壊す可能性がある」作業 → 切る
「ちょっとメモ追加」程度                  → mainに直接でもOK
「実験的に試したい」                       → 切る（失敗したら丸ごと捨てられる）

R2R2Rで言うと「新しいピックアップロジックを試す」時にブランチを切る習慣をつけると、LOG83のような事故が防げる。あのとき実験用ブランチを切っていれば、mainのコードは無傷だった。

今はこの3つを優先順位として持っておく。

1. 今すぐやる：.gitignore（Unity・Node.js用テンプレートを適用）→ 完了

2. 習慣にする：ブランチを切る（実験・大きな変更のとき）

3. 知識として持つ：コンフリクト解消、GitHub Actionsの概念

今日の全リポジトリ状況

r2r2r-scriptsについては、「自分だけが使うスクリプト集はGitHub pushは不要」と判断してローカル管理のままにした。これはツールの性質にあわせてシンプルに決めた判断だ。

教訓は「コミットしていたから戻れた」だった。 今の教訓は「コミットしてはいけないものがある」だ。

同じGitでも、見えている景色が全然違う。

※ プロジェクト名「R2R2R」は、UC Berkeley・Toyota Research Instituteの研究「Real2Render2Real」（Yu, Fu et al., 2025）の概念に触発されています。現実空間をデジタルツイン化し、仮想空間での試行から得た知見を実世界のモーター駆動へ還元する——その設計と実装過程を毎日記録しています。技術アプローチおよび目的は独自のものです。