3. GitHub に公開する

手元で完結していた履歴を、インターネット上に置きます。

3-1 なぜ GitHub に置くのか

理由は3つです。

1. バックアップ：PC が壊れても履歴が失われません
2. 共有：他の人が読めて、変更を持ち寄れます
3. 可搬性：別の PC で続きの作業ができます

3-2 ローカルとリモート

2-4 の3つの箱の右に、4つ目の箱が増えます。

flowchart LR
  subgraph local["自分の PC"]
    direction LR
    wt["作業ツリー"] --> stage["ステージ"] --> repo["ローカルリポジトリ"]
  end
  subgraph remote["GitHub"]
    rrepo["リモートリポジトリ"]
  end
  repo -- "push" --> rrepo
  rrepo -- "pull" --> repo
  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 wt,stage work
  class repo local
  class rrepo remote
  style local fill:none,stroke:#3b82f6,stroke-dasharray: 4 4
  style remote fill:none,stroke:#8b5cf6,stroke-dasharray: 4 4

押さえるところは2つです。

GitHub に置いた後も、自分の PC の履歴はそのまま残ります。 移動ではなく複製なので、同じ履歴が2か所にある状態になります。

そして、この2つは自動では揃いません。 push と pull という明示的な操作をしたときだけ、内容が行き来します。

クラウドストレージとは違う

Google Drive や OneDrive は、保存した瞬間に勝手に同期します。 GitHub は同期しません。

コミットしても GitHub には何も届いていません。 この違いは 3-5 で実際に確認します。

3-3 やってみよう：GitHub に公開する

2択の文言は VS Code とその拡張機能のバージョンによって変わりますが、非公開と公開のどちらかを選ばせる形は同じです。

1. ソース管理ビューの「Branch の発行」（Publish Branch）ボタンを押します
2. リポジトリ名を確認します（既定はフォルダ名です）
3. 公開範囲を選びます
   • Public は誰でも見られる状態です
   • Private は自分と招待した人だけが見られる状態です
   • 練習用のリポジトリは Private を選んでください
4. ブラウザで GitHub を開き、ファイルが上がっていることを確認します

「発行」ボタンが見当たらない場合は、まだ1回もコミットしていない可能性があります。

3-4 やってみよう：GitHub 上で履歴を読む

GitHub の画面のどこに何があるかを、実際に触って覚えます。

見たいもの	場所
コミット履歴	ファイル一覧の上の「Commits」
あるファイルの変更履歴	ファイルを開いて「History」
1つのコミットの中身	履歴からコミットをクリック（赤と緑の差分）
どの行を誰がいつ書いたか	ファイルを開いて「Blame」

Blame は名前が物騒ですが、責任を追及するための機能ではありません。 この行がなぜ書かれたのかを辿るために使います。 「この謎の待ち時間、何のために入れたんだろう」と思ったとき、その行のコミットメッセージまで一息で辿れます。

3-5 やってみよう：push を体験する

1. profile.md をもう一度編集して保存します
2. ステージしてコミットします
3. この時点で GitHub のページを再読み込みします。まだ何も変わっていません
4. ソース管理ビューの「変更の同期」ボタンを押します
5. GitHub を再読み込みします。今度は反映されています

3 を飛ばさないでください。 コミットすれば GitHub に上がる、という誤解はここで潰せます。

コミットは自分の PC の中で記録する操作、push は GitHub に送る操作です。 別の操作なので、片方だけやっても片方は起きません。

3-6 pull はいつ使うのか

一人で作業しているあいだは出番がありません。 必要になるのは、GitHub 側が自分の手元より進んでいるときです。

• GitHub の画面で直接ファイルを編集したとき
• 他のメンバーが変更を上げたとき（5. Pull Request で共同作業する）

試すなら、GitHub の Web 画面で README.md を新規作成してから、VS Code で「変更の同期」を押してみてください。 作ったファイルが手元に降りてきます。

3-7 リポジトリに入れてはいけないもの

Git は、指定しない限りフォルダの中のすべてを記録の対象にします。 そのため、履歴に入れたくないファイルは、入れないと明示する必要があります。 そのための設定ファイルが .gitignore で、書き方は 付録D にあります。

秘密情報をコミットしない

Wi-Fi のパスワード、API キー、個人情報を含むファイルは、絶対にコミットしないでください。

一度コミットすると履歴に残り、後からファイルを削除しても過去のコミットからは読めます。 公開リポジトリなら、その時点で漏洩したものとして扱わなければなりません。

3-8 つまずきポイント

症状	原因	対処
認証を求められて進めない	GitHub のサインインが未完了	0-5 を実施し、VS Code を再起動する
remote: Permission denied	別アカウントの認証情報が残っている	VS Code のアカウントからサインアウトし、再サインインする
push したのに GitHub に出ない	別のブランチに push している、または画面のキャッシュ	ブランチ名を確認し、再読み込みする
リポジトリ名を間違えた	—	GitHub の Settings から改名できる。手元のリモート URL も更新が必要

3-9 GUI と CLI の対応表

VS Code の操作	コマンド
Branch の発行	git remote add origin <URL> と git push -u origin main
変更の同期	git pull と git push
送るだけ	git push
受け取るだけ	git pull
リモートの確認	git remote -v

チェックポイント

• GitHub 上に自分のリポジトリがある
• GitHub でコミット履歴と差分が読める
• コミットと push の違いを説明できる
• GitHub のファイルと手元のファイルが自動で同期しないことを理解している