7. 困ったときの対処法

この章の目的は、詰まったときに諦めないことです。上から読む章ではなく、困ったときに引く章として書いてあります。

7-1 コミットさえしていれば戻せる

コミットしたものは、そう簡単には消えません。だから、怖い操作をする前にコミットしておくのが最も効く防御です。

そして最強の逃げ道があります。

7-2 よくある場面と対処

flowchart TD
  q["何かおかしい"] --> a{"コミットしたか"}
  a -- "まだしていない" --> b["変更を破棄すれば元通り"]
  a -- "した" --> c["履歴から戻せる。消えていない"]
  a -- "何が起きたか分からない" --> d["フォルダをコピーして退避してから人に聞く"]
  classDef local fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
  classDef remote fill:#ede9fe,stroke:#8b5cf6,color:#4c1d95
  classDef work fill:#f1f5f9,stroke:#94a3b8,color:#334155
  classDef safe fill:#dcfce7,stroke:#22c55e,color:#14532d
  classDef alert fill:#fef3c7,stroke:#f59e0b,color:#78350f
  class q,a work
  class b,c safe
  class d alert

場面	どうするか	VS Code	コマンド
編集を全部なくして元に戻したい（コミット前）	変更を破棄する	ソース管理の `↺`	`git restore <ファイル>`
ステージしたのを取り消したい	ステージを解除する	ファイル名右の `−`	`git restore --staged <ファイル>`
直前のコミットメッセージを直したい	修正コミットにする	`…` から「最後のコミットを修正」	`git commit --amend`
間違ったブランチで作業した（コミット前）	そこでブランチを作れば持っていける	新しいブランチの作成	`git switch -c <新ブランチ>`
push できない	先に pull する	変更の同期	`git pull`
昨日の状態のファイルが見たい	履歴からファイルを開く	履歴からコミットを開く	`git show <コミット ID>:<ファイル>`
マージしたけれどやめたい（PR 済み）	打ち消すコミットを作る	GitHub の PR 画面の `Revert`	`git revert <コミット ID>`
完全に分からない	フォルダをコピーして退避し、人に聞く	—	—

7-3 やってはいけないこと

やってはいけないこと	なぜ
パスワードや API キーや個人情報をコミットする	履歴に残り、消すのが極めて難しい。公開リポジトリなら漏洩する
`git push --force` を使う	他の人の作業を消す可能性がある
数百 MB を超えるファイルをコミットする	リポジトリが肥大化して、clone する全員が待たされる
意味の分からないコマンドをコピーして実行する	何が起きたか分からず、復旧もできない

3つ目は、このゼミでは現実的な危険です。ダウンリンクしたテレメトリのログ、カメラで撮影した画像、build/ の中のビルド成果物は、放っておくとすぐに膨らみます。 GitHub には1ファイル100 MB の上限があり、リポジトリ全体でも1 GB 以内が推奨されています。これらは .gitignore で除外し、必要なら別の場所で共有してください。

7-4 調べ方と助けの求め方

エラーメッセージは、要約せずにそのままコピーして検索してください。自分の言葉に直すと、同じ症状の記事に当たらなくなります。英語のエラーは翻訳にかけてかまいません。

人に聞くときは、次の3点を伝えてください。

何をしようとしたか
何をしたか（実行した操作やコマンド）
何が起きたか（エラーメッセージの全文、または画面の写真）

生成 AI に聞くときも同じ3点を伝えます。ただし、返ってきたコマンドをそのまま実行する前に、それが何をするコマンドなのかを確認してください。 --force や reset --hard を含む提案は、確認せずに実行するわけにはいきません。

7-5 この先の学び方

いま覚えた操作だけで、一人の作業もチームでの共同作業も回ります。まず使ってみるのが一番の練習です。

次に触るとよいものを挙げておきます。

Issue：やることと困りごとを記録して議論する場所
GitHub Actions：テストやビルドを自動で走らせる仕組み

ブランチ戦略や rebase は、必要になってからで間に合います。