Git 01 考え方(リポジトリ・コミット・3つの場所)
更新日:
なぜバージョン管理が必要か
Git なしだとこうなりがち:
index.html
index_修正.html
index_修正2_最終.html
index_最終_本当に最終.html- どれが最新かわからない、何を変えたかわからない、壊れたときに戻れない
- 複数人(+AI)で同じファイルを触ると上書きし合う
Git を使うと:
- ファイルは常に1つ。過去の状態は Git の中に履歴として残る
- 「どこを・なぜ変えたか」がコミットごとに見える
- 試しに大胆に変えても、ブランチで隔離して、ダメなら捨てられる
スナップショットとして記録する
Git はコミットのたびに「プロジェクト全体のその瞬間の写真(スナップショット)」を撮る。変更のないファイルは前の写真を使い回すので軽い。
コミットA ── コミットB ── コミットC ← main(ブランチ) ← HEAD(今ここ)
「初期作成」 「ヘッダー追加」「色を修正」- 各コミットには ハッシュ(ID) が付く。例:
a1b2c3d(長い ID の先頭7文字で呼ぶことが多い) - コミットは「親」を指していて、それを辿ると歴史になる
3つの場所(ここが一番大事)
作業ツリー ステージ(インデックス) リポジトリ(.git)
(実際のファイル) ─ git add → (次のコミット候補) ─ git commit → (履歴として確定)
↑ │
└────────────────── git restore / git switch ──────────────────┘| 場所 | 何か | 例え |
|---|---|---|
| 作業ツリー | エディタで編集している普通のファイル | 机の上の書類 |
| ステージ | 「次のコミットに入れる」と選んだ変更 | 封筒に入れた書類 |
| リポジトリ | 確定した履歴(.git/ フォルダの中) | 金庫にしまった記録 |
- なぜステージがあるか: 関係のある変更だけを1つのコミットにまとめるため(例: バグ修正とデザイン変更を別々のコミットにする)
- ファイルの状態: 未追跡(untracked)→ 変更あり(modified)→ ステージ済み(staged)→ コミット済み(committed)
ローカルとリモート
[自分のPC: ローカルリポジトリ] ── push ──→ [GitHub: リモートリポジトリ(origin)]
←─ pull ──- Git は分散型: 全員の PC に完全な履歴のコピーがある。オフラインでもコミットできる
- 共有するのはリモート(GitHub など)。push するまでは自分の PC にしかない
よくある誤解
| 誤解 | 実際 |
|---|---|
| 保存(Cmd+S)すれば記録される | ファイル保存とコミットは別。コミットして初めて戻れる |
| コミットすれば GitHub に上がる | push しないと上がらない |
| Git は何でも戻せる | 戻せるのはコミットしたファイルだけ。DB の中身や送信済みメールは無理 |
.git フォルダは消しても平気 | 履歴がすべて消える。触らない |
| Git と GitHub は同じもの | 道具とサービス。GitLab など他の置き場もある |