初学者のための「読む・戻す」最小Git-CLIチュートリアル
対象：GUI（Visual Studio / GitHub Desktop など）を主に使う人が、復旧と読解のために最低限のCLIを身につけるための記事
今日使う7コマンド：
git status / git log –oneline –graph –decorate / git reflog / git restore . / git reset –hard <hash> / git pull –rebase / git push
目次
0. 学びのゴール
- 変更状況を読める（status / log）
- ミスっても戻せる（restore / reflog / reset）
- リモートと安全に同期できる（pull –rebase / push）
実務では日常はGUI、困ったらこの最小CLIに切り替えるイメージです。
1. 演習用リポジトリを作る（5分）
既存リポがあればこの章は飛ばしてOK。新規で練習用を作る場合：
# 作業用ディレクトリを作って移動
mkdir .\git-cli-tutorial; if ($?) { Set-Location .\git-cli-tutorial }
# 新規リポ（デフォルトブランチを main に）
git init -b main
# ファイル作成 → 3回コミットして履歴を用意
echo "v1" > app.txt
git add app.txt
git commit -m "v1"
echo "v2" >> app.txt
git commit -am "v2"
echo "v3" >> app.txt
git commit -am "v3"2. 状態を読む：git status と git log
2-1. いまの作業ツリー（status）
git status- modified / staged / untracked の区別が分かればOK。
- 迷ったらまず status。毎回叩くくらいでちょうど良いです。
2-2. 履歴の骨格（log –oneline –graph –decorate）
git log --oneline --graph --decorate --all例（ハッシュは環境で異なります）：
* 9f2c1e1 (HEAD -> main) v3
* 6a7b2de v2
* 1a0c9b4 v1- HEAD -> main が現在位置。
- –graph でブランチの分岐/統合が見える。
- 「どこまで戻す？」の判断材料は常に log です。
3. 作業3. 作業を戻す（未コミットの変更）：git restore .
意図せず壊した作業ツリー（未コミット）を最新コミットの状態に戻す：
# 誤って壊す（練習）
echo "oops" >> app.txt
# 変更を確認
git status
# -> modified: app.txt
# すべてのファイルを最新コミットに戻す
git restore .
# 念のため
git status # -> clean- restore . はワークツリーの変更を捨てます。
- ステージ済みの変更を戻すときは git restore –staged <file>（今回は触れませんが用語だけ覚えておくと◎）。
注意：未追跡（untracked）ファイルの削除には効きません。誤って大量生成してしまった場合はGUIで拾い直すか、別の対処が必要です。
4. 誤コミットの復旧：git reflog → git reset –hard <hash>
誤ってコミットしてしまった場合、「どの時点に戻すか」を自分のHEADの移動履歴から探します。
4-1. まずは救命索：reflog
git reflog例：
9f2c1e1 (HEAD -> main) HEAD@{0}: commit: v3
6a7b2de HEAD@{1}: commit: v2
1a0c9b4 HEAD@{2}: commit (initial): v1- HEAD@{1} のひとつ前など、戻したい地点が分かります。
- reflog はローカル限定の履歴。リモートに影響しません。
4-2. その地点へ完全に巻き戻す：reset –hard
演習は必ず自分のローカル or 自分の feature ブランチで。共有ブランチ（mainなど）に対して履歴を書き換えるのはNG。
# 例：v2 のコミットに戻す（ハッシュは例）
git reset --hard 6a7b2de確認：
git log --oneline --graph --decorate
# -> 先頭が v2 になっていればOK
type app.txt
# -> v1 と v2 の2行だけが残っているもし「戻しすぎた」なら、もう一度 git reflog を見て、戻る直前のハッシュに reset –hard すれば復旧できます。
5. リモートと同期：git pull –rebase → git push
5-1. pull の基本方針
- –rebase：自分のローカルコミットを最新のリモート履歴の上に並べ替える。履歴が直線的になってレビュー/追跡が楽。
- チームで「pull は rebase を使うか」を統一しておくと事故が減ります（VSの設定でも統一可能）。
5-2. 実行と読み方
git pull --rebase- 競合が出たらGUIのマージエディタで解消 → 再試行（git rebase –continue は今回は触れません。実務ではGUIで完了させてOK）。
5-3. 反映（push）
git push- ブランチ保護（レビュー必須/CI必須/直push禁止など）が有効な場合、PRを作成してレビューを通します。
- reset –hard で履歴を書き換えたブランチをそのまま共有に押し上げるのは原則NG（forceが必要になり、他人の履歴を壊します）。演習は必ず個人ブランチで。
6. 2つの代表シナリオ（手を動かす練習）
シナリオA：未コミットの壊れた変更を捨ててやり直す
- ファイルを壊す
echo "broken" >> app.txt- 状態を見る
git status- 差分を捨てる
git restore .- 履歴を確認
git log --oneline --graph --decorateシナリオB：誤コミットをなかったことにして整える（ローカルの feature ブランチで）
- もう1回コミットしておく（わざと誤コミットを作る）
echo "bad change" >> app.txt
git commit -am "bad commit"- 直近の移動履歴を確認
git reflog- 誤コミット直前のハッシュに巻き戻し
git reset --hard <good-hash>- 最新のリモートの上に並べ替え
git pull --rebase- リモートに反映（PR前提）
git push7. よくある落とし穴と回避策
- mainでreset –hard：共有履歴を破壊するのでNG。個人ブランチでのみ実施し、共有にはPRで戻す。
- 未追跡ファイルが大量に残る：restoreでは消えません。まずはGUIで内容確認→不要ならIDEやOS側で整理。
- pull時に競合だらけ：GUIのマージエディタで落ち着いて1つずつ解消。解消後はビルドとテストを必ず。
8. まとめ（運用の指針）
- 読む：status / log を習慣化。
- 戻す：未コミットは restore、コミット済みは reflog→reset。
- 同期：pull –rebase で直線履歴を維持し、push はPRを前提に。
- 実務では普段はGUI、非常時にだけこの最小CLIを使えるようにしておくと、事故に強くなります。
付録：コマンド小辞典（今日使ったものだけ）
- git status … いまの作業状況（未追跡/変更/ステージ）
- git log –oneline –graph –decorate … 履歴の骨格を読む
- git reflog … 自分のHEAD移動履歴（ローカル限定の救命索）
- git restore . … 未コミットの編集を最新コミットへ戻す
- git reset –hard <hash> … 指定コミットに完全巻き戻し（慎重に）
- git pull –rebase … 最新リモートの上に自分の変更を並べ替え
- git push … 変更をリモートへ反映（PR経由が原則）
訪問数 4 回, 今日の訪問数 4回