Git と GitHub の基本：ローカルから始めて GitHub につなげる

作ったコードを Cloudflare などのサービスに公開するとき、その間の ハブ として便利なのが GitHub。バイブコーディングで自分のコードを世に出すには、まず手元の Git とそれを置く GitHub の組み合わせを整えておくとよい。

本記事は Mac（MacBook など）ユーザー向けに書いているが、Windows でも同じ手順で進められる。Google アカウントを持っていることが前提（GitHub のアカウント作成で使う）。Claudeデスクトップアプリ（→ CDG）の Claude Code から進める前提で、コマンドは ビュー メニュー → ターミナル（→ CDG 5-4）で実行する。GitHub の認証は gh コマンドのブラウザ認証で完結させる。

Windows の人へ: Mac と違うのは git・gh のインストール方法だけ。先に Windowsでのセットアップ（WIN）で環境を整えてから戻ってくると、以降のコマンドはそのまま動く。

1. はじめに

1-1. Git と GitHub の関係

Git はファイルのバージョン管理ツールで、手元のパソコンで動く。1つのフォルダの中の変更を コミット（commit）という単位で記録していく。このフォルダ＋履歴のセットを リポジトリ と呼ぶ。

補足: コミットについて ある時点のファイル群を、メッセージ（自分で書く説明）と一緒に保存したもの。ざっくり言えば「コメント付きのスナップショット」。作者・日時・前のコミットへの参照も持つので、コミットが鎖のように繋がって履歴になる。なお「コミット」は保存物（名詞）と、それを作る操作（動詞「コミットする」）の両方を指す。プッシュなども同様。

GitHub はそのリポジトリをネット上に置ける場所で、すべてのコミットが丸ごとクラウドに保存される。ローカルのコミットを GitHub に送ることを プッシュ（push）という。

ポイントは Git 本体はローカルで完結する こと。GitHub は「クラウドのバックアップ＆共有先」にすぎず、ローカルでコミットを重ねてからまとめてプッシュする二段構え。さらに GitHub のリポジトリは、Cloudflare との連携（後述）でそのままサイト公開にもつながる。

この記事で覚えたい用語は5つ: Git / GitHub / コミット（commit）/ リポジトリ / プッシュ（push）。ここまでで全部出そろっている。以降はこの5つを使って手を動かしていく。

1-2. なぜ Git/GitHub を使うのか

「Claude Code でファイル作るだけじゃダメなの？」「Cloudflare にデプロイするだけなら GitHub いらないのでは？」とハンズオン参加者からよく聞かれる。Git/GitHub があると、Claude Code でのコーディングも Cloudflare へのデプロイも、その後の運用も楽になる。

• Claude Code と相性がいい: AI に大胆な書き換えを頼んでも、コミットしておけば動いていた状態にいつでも戻せる。何を・なぜ変えたかもコミットメッセージとして履歴に残る。別 PC や別セッションとも GitHub 経由で同期できる
• push するだけで公開・更新できる: GitHub と Cloudflare Pages を連携させる設定をしておけば、push するだけで本番に反映される。デプロイ履歴やロールバックも自動で残る
• コードのオリジナルの保管場所になる: Cloudflare 側に残るのは公開成果物だけ。GitHub に push しておけば、Mac が壊れても取り直せる（clone）し、別マシンへの移行や引き継ぎも GitHub と Cloudflare のアカウントを渡すだけで一式が移る
• 汎用スキルとして無駄がない: Git/GitHub は世界中の開発の標準ツールで、Claude Code 自体も Git を前提に作られている（差分レビュー、コミット用ボタン）。Markdown 原稿や設定ファイルなど、テキストで書いたものは何でも管理できる

そして日常で使うのは commit と push の基本操作だけ。本記事はその最低限を体験する。全部覚える必要はないので、後は必要に応じて広げていける。

1-3. この記事で扱うこと

1. Git のインストール確認（2章）
2. ローカルで git init → コミットを何回か体験 → やり直し・巻き戻し（3章）
3. GitHub アカウント作成 + gh コマンドで GitHub につなげる（4章）
4. 日々の運用（5章）
5. 補足（6章）

2. Git の準備

Windows は Git が標準で入っていないので、WIN で Git for Windows・gh を入れてからこの先へ進む（導入済みなら読み飛ばしてよい）。以降のコマンドは Mac と共通。

2-1. Git のインストール確認

macOS には Git が標準でほぼ入っている。Claudeデスクトップアプリの ビュー メニュー → ターミナル から確認：

git --version

git version 2.x のように表示されればOK。そうでない場合、初回実行時に「Xcode Command Line Tools をインストールしますか？」と聞かれるので承認する。

3. ローカルで Git を動かしてみる

ここからは Git だけ使ってローカルで「コミット → 差分 → 巻き戻し」の流れを体験する。GitHub はまだ使わない。

3-1. 作業フォルダを作って Claude Code を起動

Finder（Windows はエクスプローラー）で ~/claude フォルダ（なければ作る）の中に練習用フォルダ git-test を作る。

Claudeデスクトップアプリを起動。

Code（Claude Code）を選択 → New session をクリック → フォルダ git-test を指定（~/claude/git-test）

~/claude はホームフォルダ（自分のユーザ名のフォルダ）の直下に作る claude フォルダのこと。~/claude の意味やホームフォルダの開き方・サイドバーへの固定方法は、ブラウザでアップロードして公開する記事で説明している。

3-2. ファイルを作る

リポジトリの説明用に README.md を作る。GitHub では README.md がリポジトリのトップページに自動で表示される慣習があり、最初に置くファイルの定番。Claude Code の入力欄に依頼する：

Claude

README.md を作って、内容は「# 私の最初のリポジトリ」だけにして。

最初の依頼を出すと、ビュー メニューに ファイル や ターミナル などが表示されるようになる。ビュー メニュー → ファイル（→ CDG 5-2）で README.md が作られていることを確認できる。

3-3. リポジトリを初期化する

ここから先は ビュー メニュー → ターミナル（→ CDG 5-4）で git コマンドを直接入力していく。コマンドをそのままチャット欄に入力して Claude Code に依頼する方法でもよい。

このフォルダを Git の管理下にする：

git init

これで .git/ という隠しフォルダができる。Git の履歴・設定はすべてここに入る。.git/ を消すと履歴も消える ので触らない。

3-4. 状態を確認してコミットする

状態を見る：

git status

「Untracked files: README.md」「README.md が untracked の状態」などと出る（まだ Git に追跡されていない状態）。

ステージング：

git add README.md

ステージングとは「次のコミットに含めるファイル」を選ぶ操作。複数ファイルを編集して一部だけコミットしたいときに使う。

コミット：

git commit -m "最初のコミット"

-m の後にメッセージを書く。これが履歴に残る説明文。

Claudeデスクトップアプリのチャット入力欄上部に 変更をコミット ボタンが出ていることがあり、ここからもコミットできる。ただし本記事ではコマンドの挙動を体感するために、ターミナルから git commit で進める。

3-5. ファイルを編集してコミット

3-4 ではターミナルの git add → git commit でコミットした。ここからは Claude Code に「コミットして」と頼むだけでも同じことができる。「小さく変える → コミット」を3回くり返して、履歴を溜めていく（あとの 3-7 で戻すのに使う）。

1回目：本文を足してコミット

README.md の2行目に「Git の練習用リポジトリ。」を追記する。

Claude

README.mdに「Git の練習用リポジトリ。」という本文を足して

自分で直してもよい。ビュー メニュー → ファイル で README.md をクリックし、右上の </> ボタンで編集モードにして2行目を入力 → 保存。どちらでも結果は同じ。

足せたらコミット：

Claude

コミットして

Claude Code が add → commit までまとめてやってくれる（コミットメッセージは変更内容から自動で決まる）。ターミナルで手を動かすなら次と同じ：

git add README.md
git commit -m "説明を追加"

2回目：川柳を足してコミット

Claude

Claude Code を題材にした川柳を1つ作って、README.md に足して

Claude

コミット

3回目：タイトルに日付を足してコミット

Claude

README.md の1行目のタイトルに、今日の日付を足して

Claude

commit

コミットの頼み方は「コミットして」「コミット」「commit」などどれでも通じる。Claude Code が意図をくんで add → commit してくれる。

こうして 「小さく変える → コミット」をこまめに繰り返すと、履歴に細かく区切りができ、あとから「あの変更の前に戻す」がやりやすくなる。次の 3-6 で git log を見ると、コミットが増えているのが分かる。

3-6. 履歴を見る

git log

これまでのコミット一覧が時系列で表示される。コミットハッシュ・著者・日付・メッセージが見える。

チャット入力欄に git log を入力して Claude Code に依頼した場合、実行結果が折りたたまれて表示されることがある。先頭の三角アイコンや「Bash …」のような行をクリックすると、中身が開いて出力を確認できる。

同じ履歴をもっと読みやすい表でも出せる：

Claude

変更履歴を表で見せて

コミット・日時・内容が表で並ぶ。3-5 で作ったコミット（最初のコミット → 本文追加 → 川柳追加 → 日付追加）がそのまま並んでいるのが分かる。

「変更履歴を表で見せて」の実行例

3-7. やり直し・巻き戻し

Git は「やり直し」が得意で、以下のような操作ができる：

• 編集を捨てて最後のコミット時点に戻す
• git add したファイルをステージから外す
• 直前のコミットメッセージや内容を直す
• 過去のコミット時点に戻る

コマンドを正確に覚える必要はない。Claude Code に「直前のコミットを取り消したい」「この編集を捨てたい」のように依頼すれば、状況に応じて適切なコマンドを実行してくれる。ここでは 3-5 で溜めたコミットを使って、実際に戻してみる。

前の状態に戻してみる

3-5 で足した川柳を、なかったことにしてみる。Claude Code にこう頼む：

Claude

README.md に川柳を足す前のコミットに戻して

「戻す先」をファイルではなく コミット で指定すると、Claude Code は手で消すのではなく git の履歴を使って戻してくれる。なお、戻し先の「川柳を足す前のコミット」は、その後に足した「日付追加」より前の地点なので、戻すと川柳だけでなく日付の変更も一緒に消える（＝その時点まで丸ごと戻る、ということ）。

このとき、戻し方には大きく 2通り あり、どちらにするかでコミット履歴の扱いが変わる。Claude Code がどちらにするか聞いてくることもあるので、違いを知っておく（先に指定して頼んでもよい）。

(A) ファイルだけ前の状態に戻す（履歴は残る。ふだんはこちら）

• 川柳を消した内容に戻し、それを新しいコミットとして記録する形。「足した」も「戻した」も履歴に残る
• 安全。すでに push して共有していても問題ない
• 頼み方の例：

Claude

README.md に川柳を足す前のコミットに戻して。コミット履歴は消さず、戻したことも記録に残る形でお願い

(B) コミットごと巻き戻す（履歴から消える）

• 川柳を足したコミット以降を まるごと削除 して、その前の時点に戻す
• 履歴が書き換わる＝川柳のコミットは「なかったこと」になる
• まだ公開していないローカルの実験を丸ごと捨てたいときに便利。ただし すでに push してある／他の人と共有している場合は要注意（巻き戻しを反映するには force push が必要で、共有リポジトリでは事故のもと）
• 頼み方の例：

Claude

川柳を足す前のコミットまで巻き戻して。川柳以降のコミットは履歴ごと消してOK

迷ったら (A) の「履歴を残す」が安全。Git に慣れていないうちや push 済みのときは (A)。(B) は「まだ push していないローカルの実験を丸ごと捨てたい」ようなときに使う。

4. GitHub につなげる

ローカルで作ったリポジトリを GitHub に置く。GitHub アカウントを作成し、gh コマンドで認証してからリポジトリを作る。

本サイトでは、GitHub への操作（リポジトリ作成・push など）をすべて gh コマンド（GitHub CLI）とターミナルの git で行う方針。注意が必要なのは、次の GitHub プラグイン。

• プラグイン「Github」（左下のアイコン → 設定 → カスタマイズ → プラグイン）… GitHub 公式の MCP サーバ。Claude Code に GitHub API を直接操作するツールを足す。これが入っていると gh・ローカルの git を使わず API 経由でリポジトリを触ってしまい、手元のコミットと GitHub 側がズレて手順どおりに進まないことがある。本ハンズオンの間はオフにしておくこと

⚠️ GitHub の MCP プラグインはオフにする。設定 → カスタマイズ → プラグイン に GitHub 公式の Github（MCP サーバ）があり、インストールしていなければそのままでよい。すでに入れているなら、本ハンズオンの間は無効化（またはアンインストール）しておく。なお、コネクタの「GitHub連携」とは別物。そちらはオフにしなくてよい。

gh に統一する理由は2つ。1つは、MCP プラグインが GitHub API に直接コミットする方式で、本記事で体験する「ローカルでコミット → push」の流れ（→ 1-1）と噛み合わないため。もう1つは、gh とターミナルの git はどの環境でも通用する汎用的な方法で、将来 Codex など別の AI コーディングツールに乗り換えても操作の違いが最小限で済むため。MCP プラグインは便利だが、本サイトでは汎用的な gh ルートを優先する。

公式も gh 寄り／MCP はコスト・信頼性で不利: Anthropic 公式のベストプラクティスも、外部サービス連携は CLI ツールが最も文脈効率がよいとし、「GitHub を使うなら gh CLI を入れよ」と明記している（Claude Code Best practices）。実測の差も大きく、ある比較（Claude Sonnet 4・75回試行の ScaleKit ベンチマーク）では、CLI は MCP に対し 1操作あたりのトークンが 4〜32 分の1、成功率は 100% 対 72%、月1万操作あたりのコストは 約 $3.20 対 $55.20。GitHub MCP は最初の一手の前に 93 ツール・約 55,000 トークン分の定義を読み込む（その後、既定は 52 ツールへ削減）という指摘もある（gh と MCP の比較、MCP vs CLI vs REST）。※ いずれもツール検索などの最適化が入る前の数値で、差は縮まりつつある。gh に統一するのは、初心者がつまずきにくいだけでなく、コストと安定性の面でも理にかなっている。

4-1. GitHub アカウントを作成

⚠️ GitHubのサイトにアクセスしたら、最初にChromeの自動翻訳をオフにすること。機能名（例：Actions）が「行動」のように直訳されるなど、UI全体が直訳調になって読みづらいため。Chromeの右上の ︙（メニュー） → 翻訳 → 表示されたポップアップの ︙ → このサイトは翻訳しない。

1. github.com にアクセスして Sign up for GitHub をクリック
   

   github.com

2. Googleアカウントで登録する場合は Continue with Google を選択
   

   Continue with Google

3. ユーザー名を設定して登録完了
   

   Create account

ユーザー名はURLに使われる（github.com/ユーザー名）。後から変更できるが、外部に共有したURLが変わってしまうので最初から決めておくとよい。

4-2. Git のメールアドレスを GitHub に合わせる

Git のコミットに記録されるメールアドレスを、いま作成した GitHub アカウントのメールアドレスに合わせて設定する：

git config --global user.email "github-account@example.com"

合わせておくと、GitHub 上でコミットの作者表示が自分のアカウントに紐づく（プロフィールアイコンが出る、Contributions グラフに反映される、など）。

GitHub アカウントのメールアドレスは、GitHub ページの右上の丸いプロフィールアイコン → Settings で確認できる。Public profile の Public email や、左メニュー Emails にある「Primary email address」を見る。

4-3. gh CLI のインストール

GitHub 公式の CLI ツール。gh コマンドで GitHub のリポジトリ作成や認証ができる。

Homebrew でインストール（Homebrew 自体のセットアップは Homebrew をセットアップする 参照）。Windows は winget で入れる（→ WIN）：

brew install gh

確認：

gh --version

gh version 2.x のように表示されればOK。

command not found: gh（や brew 自体が見つからない）と出る場合は、PATH やコマンドのキャッシュの問題のことが多い。新しいターミナルを開き直す・hash -r でキャッシュをクリアする、などで直る。詳しくは HBS 6. 補足 を参照。

4-4. GitHub にログインする

このコマンドは対話的にブラウザを開くため、Claude Code のチャット欄に渡さず、ビュー メニュー → ターミナル から直接実行する。チャット欄に渡すと「ターミナルから実行してください」と案内される。

gh auth login

質問が順に出るので、矢印キーで選んでいく：

• What account do you want to log into? → GitHub.com
• What is your preferred protocol for Git operations on this host? → HTTPS
• Authenticate Git with your GitHub credentials? → Y
• How would you like to authenticate GitHub CLI? → Login with a web browser

8桁のワンタイムコード（下の図では 1852-EC8A）が表示されるのでこれをコピーしておく。Enter を押すとブラウザが自動で開くので、GitHub の画面にコードを貼り付けて承認すれば認証完了。

gh auth login の画面（質問への回答とワンタイムコードの表示）

複数の GitHub アカウントを使い分けている人へ: 承認前に「いまブラウザに表示されている GitHub アカウントは想定通りか」を確認する。デフォルトブラウザのアカウント混在で意図しないアカウントに認証されることがある。詳しくは 6-6. 複数の GitHub アカウントを持っているときの注意点 を参照。

4-5. ローカルのリポジトリと GitHub をつなげる

~/claude/git-test にいる状態で、Claude Code にこう頼む：

Claude

GitHubに非公開のリポジトリ git-test を作って、今のフォルダの内容をpushして

これで GitHub 上にリポジトリが作られ、リモート（origin）が登録され、ここまでのコミットの push まで一気に完了する。認証（4-4 の gh auth login）さえ済んでいれば、リポジトリ作成からはチャットで頼める。

裏では次の gh コマンドが動いている。手で打ってもよいし、オプションの意味を知っておくと応用が利く：

gh repo create git-test --private --source=. --remote=origin --push

• --private: 非公開リポジトリで作る（--public にすれば公開）
• --source=.: カレントディレクトリを使う
• --remote=origin: リモート名を origin で登録
• --push: ここまで作ったコミットを GitHub に押し上げる

5. 日々の運用

5-1. コミットを GitHub に反映する

4-5 で最初の push をしたとき、upstream（追跡先）も記録される。以降は Claude Code に「pushして」と頼むだけで、変更を GitHub に反映できる。コミットメッセージも変更内容から自動で書いてくれる：

Claude

pushして

裏ではこんなコマンドが動いている：

git add 変更したファイル
git commit -m "○○を修正"
git push

ターミナルから手で入力することもできるが、基本は「pushして」と頼むのが楽。

5-2. 「変更 → push」を繰り返す

5-1 の要領で「変更 → push」を何回かやってみる。push の頼み方も「プッシュして」「push」などどれでも通じるし、編集と push を1つの依頼にまとめてもいい。

1回目：短文を足して push

Claude

カフェオレについての200文字の短文をREADME.mdに足して

Claude

プッシュして

2回目：コピーを足して push

Claude

AI使う人でGitHub使ってないとやばい！的な煽りコピーを3つREADME.mdに足して

Claude

push

3回目：編集と push をまとめて頼む

Claude

タコライスのレシピを100文字でREADME.mdに書いてpush

3回目のように「書いて push」とまとめて頼めば、Claude Code が編集 → コミット → push まで通してやってくれる。push するたびに GitHub 側が最新になり、GitHub のリポジトリページを開くと README.md が更新されているのが分かる。

6. 補足

ハンズオンを進めるうえでは必須ではないが、知っておくと困らない話題をまとめる。

6-1. すでに GitHub にあるリポジトリを使う

別の端末で作ったリポジトリ、チームで作成済みのリポジトリ、他人が作ったものを取り込みたい場合の流れ。最初のハンズオンでは使わないが、知っておくと混乱しない。

6-1-1. リポジトリを取得する（clone）

GitHub 上にあるリポジトリを手元に取得する：

cd ~/claude
gh repo clone ユーザー名/リポジトリ名
cd リポジトリ名

gh repo clone は内部で git clone を呼ぶが、URL を自動補完してくれるので楽。

6-1-2. GitHub の更新を取り込む（pull）

他の人が GitHub に push したり、自分が別の端末から push した変更を、いま手元にいるリポジトリに取り込む：

git pull

pull = fetch + merge で、GitHub の最新を取得してローカルにマージする。

6-1-3. clone と pull の使い分け

状況	使うコマンド
GitHub にあるリポジトリを手元に「初めて」取得	gh repo clone または git clone
すでに手元にあるリポジトリに、GitHub の最新を「取り込む」	git pull

clone は新しいフォルダができる。pull は既存のフォルダの中で動く。

6-2. リポジトリを Private にする

リポジトリを Public（公開）にしていると、ファイルの中身や変更履歴は誰でも閲覧できる状態になる。HTML + JavaScript + CSS だけのシンプルなアプリであれば大きな問題になることは少ないが、以下のようなケースでは Private（非公開）への変更がおすすめ。

• 試行錯誤の履歴を見られたくない
• 意図しないファイルを公開してしまうリスクを避けたい

変更方法：リポジトリの Settings → Danger Zone（ページ下部） → Change repository visibility

本記事の手順（4-5）では --private で作成しているので、初期状態から Private。Public/Private を後から切り替えたくなったときの参考までに。

6-3. アップしたくないファイルの設定

.gitignoreギット イグノア は「GitHub にアップしたくないファイル」のリストを書いておくファイル。

対象の例：パスワード・API キー / node_modules（大量の依存ファイル）/ .DS_Store（macOS が自動生成する不要ファイル）

.gitignore ファイルをターミナルで作成する例。

echo ".DS_Store" >> .gitignore
echo "node_modules/" >> .gitignore

うっかり秘密情報を公開してしまうのを防ぐ。プロジェクト作成時に設定しておくのが基本。
ただし、.gitignore は「まだ Git で管理していないファイル」を除外するためのもの。すでに追加済みのファイルは別途対処が必要なので、最初に設定しておくと混乱しにくい。
macOS では .DS_Store が頻繁に生成されるので、最初から除外しておくとよい（Windows なら Thumbs.db / desktop.ini が同様の自動生成ファイル）。

6-4. github.dev（ブラウザで VS Code）

GitHub のリポジトリページで . キーを押すと、ブラウザの中に VS Code がそのまま立ち上がる。これが github.dev という公式機能で、完全無料・ログインだけで使える。

github.dev でリポジトリを開いたところ

起動方法は2つ。

• リポジトリページで . キーを押す（一番手軽）
• URL の github.com を github.dev に書き換える

ブラウザ内でファイルを編集してそのままコミットまでできる。インストール不要・セットアップ不要なのが大きい。普段 Mac で作業しているけれど、ちょっと別の PC から md ファイルを修正したい、というときに便利。

リポジトリの Code ボタンから Codespaces を開く選択肢もあるが、それは別サービス（クラウド上の Linux 環境で VS Code を動かす、ターミナル付き、無料枠は月60時間まで）。github.dev とは URL も中身も異なる。

ただしターミナルは使えないので、git コマンドを叩く操作はできない。あくまで「ファイル編集とコミット」までの軽い用途。本格的な開発はローカル（Claude Code など）に戻ることになる。

元の GitHub のページ（github.com）に戻りたいときは、左下のステータスバーの GitHub 表示部分をクリックして リポジトリに進む を選ぶか、URL の github.dev を github.com に書き換える。

6-5. Claude × GitHub の連携機能とローカル開発

Claudeデスクトップアプリには、GitHub と連携する機能がいくつかある（GitHub 連携、GitHub Plugin など）。だが、これらは GitHub サーバー側を操作する仕組み であって、ローカルのフォルダで開発する方法 とは別物。

本サイトでは、ローカルのフォルダで Claude Code を使って編集・動作確認しながら、push してリモートに反映する開発スタイルを採用している。Claude 提供の GitHub 連携機能はサーバー側操作なので、この開発スタイルの代わりにはならない。

6-6. 複数の GitHub アカウントを持っているときの注意点

仕事用・個人用と GitHub アカウントを使い分けている場合、gh auth login のブラウザ起動で意外と詰まりやすい。よくあるトラブルと対処を整理しておく。

6-6-1. よくあるトラブル

デフォルトブラウザが GitHub を使ってるブラウザと違う

gh auth login は OS の既定ブラウザを開く。たとえば Mac で普段は Chrome で GitHub にログインしているのに、既定ブラウザが Safari のままだと、Safari が開いてしまう。Safari に GitHub のログイン状態がなければそこで改めてログイン要求が出るし、別アカウントで Safari にログインしていた場合は意図しないアカウントで承認してしまう。

対処：

• ターミナルに表示される URL（https://github.com/login/device）を手動でコピーして、いつも使うブラウザに貼り付けて開く
• もしくは OS の既定ブラウザを変更しておく（macOS は システム設定 → デスクトップとDock → デフォルトのWebブラウザ。Windows は既定のブラウザ設定から変更）

同じブラウザでもプロファイル違い・アカウント違い

Chrome のプロファイルを複数使い分けていて、それぞれで別の GitHub アカウントを使っている場合、gh auth login で開いた Chrome ウィンドウが想定したプロファイルではない、ということもある。気づかず承認すると、その後の gh repo create で意図しないアカウント側にリポジトリができてしまう。

対処：承認ボタンを押す前に、ブラウザ右上のプロファイル表示と GitHub の右上アカウントアイコンを確認する。

6-6-2. 状態確認とアカウント切替

gh 自体は複数の GitHub アカウントを並行して保持できる。状態確認と切替は以下のコマンドで行う。

コマンド	動作
gh auth status	認証済みアカウント一覧と現在のアクティブを確認
gh auth login	新規アカウント追加
gh auth switch	対話的にアクティブを切替
gh auth switch --user <username>	ユーザー名指定で切替
gh auth logout	ログアウト（複数あれば対話的に選ぶ）

例：tatsuwo-dayo がアクティブで、yto アカウントでリポジトリを作りたいとき：

gh auth switch --user yto
gh repo create my-repo --private --clone
gh auth switch --user tatsuwo-dayo

gh auth switch は GitHub CLI v2.40（2023年末）で追加された比較的新しいコマンド。「unknown command」と言われたら brew upgrade gh（Windows は winget upgrade GitHub.cli）で更新する。

6-7. GitHub Pages で公開する

GitHub に push したファイルは、GitHub Pages でそのまま Web 公開できる。リポジトリの設定画面から数クリックで完了し、https://ユーザー名.github.io/リポジトリ名/ の形式で URL が発行される。

ただし、無料版（GitHub Free）では Public リポジトリでないと GitHub Pages を使えない。本記事の git-test は Private で作ったので、試すには Public に変更する（→ 6-2 の逆操作。Settings → Danger Zone → Change repository visibility）か、gh repo create --public で作った別のリポジトリを使う。

1. リポジトリの Settings を開く
2. 左メニューの Pages を選択
3. Source を Deploy from a branch に設定
4. Branch を main、Folder を / (root) にして Save
   

   Branch

5. Pages設定画面の上部にURLが表示される（https://ユーザー名.github.io/git-test/）。反映まで数分かかるので、しばらく待ってからアクセスして確認する

注意点：

• 最初に表示されるのは index.html。git-test のように index.html が無く README.md だけの場合は、README の内容がレンダリングされて表示される。index.html を push すればそれがトップになる
• あくまで静的サイト（HTML/CSS/JSなど）が対象。サーバー側の処理が必要なものは別途対応が必要
• 公開をやめたいときは Settings → Pages の Source を None に戻す

ポートフォリオや静的なブログの公開によく使われる。本サイトのハンズオンで使う Cloudflare Pages（→ CGT）の GitHub 版にあたる機能で、push すると自動で公開内容も更新される。

6-8. SSH で GitHub に接続する

本記事の流れでは gh auth login（→ 4-4）が git の認証（HTTPS）まで面倒を見てくれるので、SSH の設定は不要。すでに SSH で GitHub を使っている人や、SSH 接続にしたい人向けに手順をまとめておく。一度設定すれば、その後はパスワードなしで操作できる。

6-8-1. GitHub に登録されているメールアドレスを確認する

GitHub → 右上のアイコン → Settings → Emails

ここに表示されているメールアドレスを次のステップで使う。Google連携でGitHub登録した場合、GmailアドレスとGitHubに登録されているアドレスが異なる場合があるので必ず確認すること。

6-8-2. SSHキーを生成する

ssh-keygen -t ed25519 -C "確認したメールアドレス"

実行後は Enter を3回押すだけでOK。アスキーアートっぽいのも出てくるが問題なし。

すでに ~/.ssh/id_ed25519 がある場合は Overwrite (y/n)? と聞かれる。既存のキーをそのまま使うなら n（または Enter）で抜けて次に進む。新しく作り直したい場合のみ y（既存の鍵は失われるので、他で使っていないか確認すること）。

6-8-3. 公開鍵を GitHub に登録する

公開鍵をクリップボードにコピーする：

pbcopy < ~/.ssh/id_ed25519.pub

Windows（Git Bash）では pbcopy の代わりに clip < ~/.ssh/id_ed25519.pub を使う。

GitHub → Settings → SSH and GPG keys → New SSH key でフォームを開き、以下を入力して Add SSH key をクリック。

フィールド	入力内容
Title	この端末の識別名（例：MacBook Air）。何でもOK
Key	コピーした公開鍵をペースト

6-8-4. 接続確認

ssh -T git@github.com

Hi ユーザー名! と表示されれば成功。

うまくいかない場合は、-v（verbose）を付けて詳細ログを取り、その内容を Claude Code に貼って原因を相談する。

ssh -vT git@github.com

失敗の原因は環境によって違う（過去に別アカウントを作っていた、SSHエージェントに鍵が読み込まれていない、会社ネットワークでポート22がブロックされている、など）。詳細ログを見れば多くの場合は原因が特定できる。

6-9. ブランチ

本番ファイルを直接触らず、コピーして作業してからOKなら合流させる仕組み。

main（本番・完成版）→ ブランチを作る（コピー）→ 作業・テスト → merge（合流）

main
├── feature ブランチ（新機能を試す）
└── fix ブランチ（バグ修正用）

GitHubでは、「このブランチの変更を main に取り込んでください」と依頼する仕組みを Pullプル Requestリクエスト（PR） と呼ぶ。PR を作って確認し、問題なければ merge（合流）する。現場では「プルリク」と略されることが多い。

最初のうちはブランチを作らず、main に直接コミットしていく方針で問題ない。チームでの開発やコードレビューが必要になってきたタイミングで覚えれば十分。

6-10. コンフリクト

同じファイルを複数人（または複数Mac）が別々に編集して push しようとすると、どちらを正とするか判断できなくなる。これがコンフリクト。

発生しやすいケース：

• 複数人が同じファイルを編集した
• 自宅Macと会社Macで作業した
• WebとMacを使い分けた

mergeのときに起きやすい。解決する仕組みはあるが、git pull を習慣づけてこまめに最新状態にしておくことで防ぎやすくなる。

7. もっと詳しく

• Pro Git Book（日本語訳）：Git 公式の体系的なリファレンス
• GitHub Docs：GitHub 自体のドキュメント
• gh CLI Manual：gh コマンドの全リファレンス

Git の操作は最初の「コミットの粒度感」さえつかめば、あとは必要な場面で必要なコマンドを増やしていけばよい。