前回の続き——手元の履歴を、外へ
O-06までで、変更をコミットし、差分で確認し、ブランチで試し、マージで統合する、という手元での履歴操作が一通りそろいました。ただし、ここまでの履歴はすべて、あなたのパソコンの中だけに存在しています。パソコンが壊れれば消えますし、他の人と分け合うこともできません。この講義の役割は、その履歴を外の共有先とつなぐことです。つないで初めて、バックアップ、他のPCとの同期、協働という次の世界が開けます。
このスライドのポイント
- O-06までで、コミット・差分・ブランチ・マージという「手元での履歴操作」が一通りそろった
- しかしその履歴は、まだ自分のパソコンの中だけにある
- この講義の役割: その履歴を「共有先」と同期させ、1台のPCの外へ広げる
- これが「バックアップ・共有・複数人での協働」の土台になる
リモート・GitHub・push・pull・cloneの定義
用語を定義します。リモートとは、C-02で学んだクラウド上に置く共有用のリポジトリです。GitHubは、そのリモートを預かる代表的なサービスで、Git本体とは別物です。ここに3つの動きが加わります。pushは手元の履歴をリモートへ送ること、pullはリモートの履歴を手元へ取り込むこと、cloneはリモートから丸ごと複製して手元に作ることです。大事な性質として、手元とリモートは自動では同期しません。pushやpullを実行して初めて、両者の内容が近づきます。
このスライドのポイント
- リモート＝インターネット上（C-02のクラウド）に置く、共有用のリポジトリ
- GitHub＝そのリモートを預かる代表的な置き場サービス（参照スタック）
- push＝手元の履歴を、リモートへ送る
- pull＝リモートの履歴を、手元へ取り込む
- clone＝リモートから丸ごと複製して、手元に作る
- 重要: 手元とリモートは自動では同期しない。人が明示的にpush／pullする
なぜ必要か——そして最大の落とし穴
リモートを使わないと2つの困りごとが起きます。1つは「コミットしたのに同僚に見えない」。pushしていないからです。もう1つは「PCが壊れて全履歴が消えた」。リモートに置いていないからです。そして、最も強調したい危険があります。O-02で、秘密情報が一度履歴に入ると消しにくいと学びました。その事故が確定するのがこの場面です。秘密をpushした瞬間に事故が確定します。B-09で扱った.envのような秘密は、リモートへ送られると自分のPCの外に出て、取り返しがつかなくなります。
このスライドのポイント
- リモートを使わないと起きること
- 「コミットしたのに同僚に見えない」＝pushしていないから
- 「PCが壊れて全履歴が消えた」＝リモートに置いていないから
- 最重要の危険: 秘密をpushした瞬間に事故が確定する（B-09→O-02の伏線の最終回収）
- .env などの秘密情報は、pushする前に必ず確認して外へ出さない
構造——2つの履歴と、3つの役割
全体像を整理します。中心にあるのは、手元のローカルリポジトリと、共有先のリモートリポジトリという2つの履歴です。この間を、pushで送り、pullで取り込み、必要なら手元をcloneで複製します。リモートの役割は3つです。1つ目はバックアップで、PCが壊れても履歴が残ります。2つ目は共有で、他のPCや他の人が同じ履歴を持てます。3つ目は公開で、外からアクセスできる場所に置けることです。この3つ目こそが、秘密情報を置いてはいけない理由そのものです。
このスライドのポイント
- ローカルリポジトリ（手元）とリモートリポジトリ（共有先）の、2つの履歴が並ぶ構造
- 両者を行き来する矢印がpush（送る）とpull（取り込む）、複製がclone
- リモートが果たす3つの役割
- ①バックアップ（PCが壊れても履歴が残る）
- ②共有（他のPC・他の人と同じ履歴を持てる）
- ③公開（外からアクセスできる場所に置ける＝だからこそ秘密は禁物）
具体例——2台のPCをまたいで作業する
具体的な流れを見ます。自宅のパソコンで機能を作り、コミットまで進めたらpushでリモートへ送ります。翌日、職場のパソコンでpullすると、昨日の続きの状態が手元に取り込まれ、そこから作業できます。履歴はリモートにも残るので、片方のパソコンが壊れても作業は失われません。これは、L-10で学んだバックアップのコード版に相当します。逆に、pushしていない変更は手元のパソコンの中だけにあり、どこにも共有されていない、という点も覚えておいてください。
このスライドのポイント
- 自宅PCで作業→pushでリモートへ→職場PCでpull→続きから作業できる
- リモートに履歴があるので、片方のPCが壊れても失われない
- これはL-10で学んだバックアップの、コード版に相当する
- 逆に言えば、pushしていない変更はどこにも共有されず、手元のPCにしか無い
技術サンプルカード
中心となる3つのコマンドです。pushは手元の履歴をリモートへ送り、pullはリモートの履歴を手元へ取り込み、cloneはリモートから丸ごと複製して手元に作ります。読み方で大切なのは2点です。1点目、pushの前には、logで「これから何を送るのか」を必ず確認する習慣を持つこと。2点目、秘密が混ざっていないかを確かめるのは、push前が最後の関門だということです。AIにpushを頼むときは、秘密情報が含まれていないかを確認させる一言を添えてください。
混同しやすい概念——コミットとpush
間違えやすい2つの操作を区別します。コミットとpushです。O-03のコミットは変更を手元の履歴に確定する操作、pushはその手元の履歴をリモートへ送る操作で、両者は別物です。コミットしただけでは、変更はまだあなたのパソコンの中にしか存在せず、共有もバックアップもされません。それが効くのはpushして初めてです。「保存したのに相手に届かない」と感じたときは、たいていコミットで止まっていて、pushを忘れています。
このスライドのポイント
- 「コミット」と「push」は別の操作
- コミット＝手元の履歴に変更を確定すること（O-03）
- push＝その手元の履歴を、リモートへ送ること
- コミットしただけでは、変更は手元のパソコンの中にしか無い
- 共有・バックアップされるのは、pushして初めて
バイブコーディングでの確認点——push前チェック
バイブコーディングでの確認点は、push前チェックを定型にすることです。送る前に、diffで実際の変更内容を、logで送るコミットの並びを確認し、「秘密や依頼外の変更が混ざっていないか」を自分の目で通します。1つ注意です。私有リポジトリ、つまり自分だけがアクセスできる設定でも、秘密のpushは避けてください。アクセス権は後から変わることがあるからです。AIに作業を任せたときほど、この最後の関門は人間が通すと決めておいてください。
このスライドのポイント
- push前チェックを定型にする: 「diffとlogに、秘密情報や依頼外の変更はないか」
- diff（O-04）で実際の変更内容を確認し、logで送るコミットを確認する
- 私有（プライベート）リポジトリでも、秘密のpushは不可（アクセス権は後から変わりうる）
- AIに作業させた後ほど、この最後の関門を人間が通す
まとめと次回
一問一答です。コミットした変更が共有先に反映されないのはなぜでしょうか。……答えは、pushしていないからです。コミットは手元に確定するだけで、リモートへ届けるのはpushの役目でした。30秒まとめです。リモートは共有用の履歴で、pushで送り、pullで取り込み、cloneで複製します。そしてpushの前には、秘密が混ざっていないかを必ず確認する。ここが、B-09から続いた秘密情報の話の最終地点でした。次回は、共有の上に乗る協働の作法、Issue・Pull Request・レビューへ進みます。
このスライドのポイント
- 一問一答: コミットした変更が共有先に反映されないのはなぜ？
- 30秒まとめ: リモートは共有用の履歴。push（送る）・pull（取り込む）・clone（複製）で手元とつなぐ。push前に秘密がないか必ず確認
- 次回: 共有の上に乗る協働の作法、Issue・Pull Request・レビューへ
- 関連資料: 「Git・GitHub 完全入門」「Vercel公開 完全手順書」
