Git — 変更履歴を記録して、いつでも戻れる

1回の記録＝コミットは、その時点のスナップショット（※1 作業場所を丸ごと写した1枚）です。差分だけでなく「その瞬間の全体像」を指し示し、各コミットは1つ前の親コミットを覚えています。

だから履歴はスナップショットの連なりになります。連なりをたどれば必ず過去の完全な状態に戻れる——これが「安全」の正体です。1点でも独立して残っているので、途中が壊れても後ろの記録は無傷です。

登場人物メモ:

• ※1 スナップショット — その時点のファイル全体を写した記録の1枚
• ※2 HEAD — 「いま自分が見ている／作業している位置」を指す目印
• ※3 リモート — GitHub などの共有先。手元の履歴を送受信する相手

• ブランチ — 履歴を枝分かれさせる。main（本流）を壊さず、feature などの枝で新機能を試せる
• マージ — 枝を本流に統合する。枝の変更を取り込んで1つに合流させる

下の図は、mainの連なりから途中で feature が分かれ、最後にmainへマージ（合流）する流れです。

枝を切るのが軽いのは、コミットが独立したスナップショットで、ブランチはその1点を指す名札にすぎないから。だから「試してダメなら枝ごと捨てる」が気軽にできます。

1. 変更をステージに載せる（記録する範囲を選ぶ）
2. コミットする（スナップショットを1枚作る）
3. 手元の履歴をリモートへ push（共有先へ送る）
4. 他の人の変更をpull（共有先から取り込む）
5. 枝ができたらマージで本流へ統合する

下の図は、手元での記録（add→commit）から共有先とのやり取り（push→pull）までを1手ずつ追ったものです。

• リモート — GitHub 等の共有先。push で送り、pull で受け取る。手元にも全履歴があるので、共有先が落ちても作業は続く
• プルリクエスト — 「この枝をmainに入れたい」というレビュー依頼の形（サービス側の機能）
• コンフリクト — 同じ箇所を別々に変えた枝を統合すると衝突する。Gitはどちらを採るか決められないので、人が見て解消する

このコミット履歴の安定性が、変更のたびに自動でテスト・デプロイする自動化（CI/CD など）の土台になります。「いつでも戻せる記録」があるからこそ、機械に任せて素早く回せます。

• コンフリクト解消のミス — 衝突を雑に消すと、必要な変更まで捨ててしまう
• 巨大なコミット — まとめすぎると、どの変更が原因か切り分けられない
• push し忘れ／pull し忘れ — 手元と共有先がずれ、あとで衝突が増える
• 秘密情報のコミット — パスワード等を記録すると履歴に残り続ける（消しても過去に残る）

土台のしくみが気になったらプログラムが動くまでや、実行環境を箱で運ぶDockerもあわせてどうぞ。