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

GBA GitGitHub

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

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

Windows の人へ: Mac と違うのは git・gh のインストール方法と、gh auth login を打つ場所だけ。先に Windowsでのセットアップ（WIN）で環境を整えてから戻ってくると、以降のコマンドはそのまま動く。ログインは、スタートメニューから開いたコマンドプロンプトで実行する（→ WIN 6-2）。

1. はじめに

1-1. Git と GitHub の関係

Git はファイルのバージョン管理ツールで、手元のパソコンで動く。1つのフォルダの中の変更を コミット（commit）という単位で記録していく。このフォルダ＋履歴のセットを リポジトリ と呼ぶ。この記録が溜まると、3-6 で「過去のことも覚えているアシスタント」として使えるようになる。

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

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. この記事で扱うこと

Git のインストール確認と初期設定（2章）
ローカルで git init → コミットを何回か体験 → やり直し・巻き戻し（3章）
GitHub アカウント作成 + gh コマンドで GitHub につなげる（4章）
日々の運用（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 をインストールしますか？」と聞かれるので承認する。

2-2. 名前とメールアドレスを登録する

Git はコミットのたびに「誰が記録したか」を残す。初回だけ、名前とメールアドレスを登録しておく。

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

--global を付けると、このパソコンのすべてのリポジトリ共通の設定になる（一度やれば以降は不要）。名前は本名でなくてよい。メールアドレスは、このあと4章で作る GitHub アカウントに使う予定のもの（Google アカウントのアドレス）を入れておく。どちらもコミットの一部として GitHub 上で公開されるので、見られて困らないものにする。

設定できたか確認：

git config --global --list

user.name=... と user.email=... の行が出ればOK。

なぜ先にやるのか: 未設定のまま git commit すると、Windows では次のエラーが出てコミットできない。
*** Please tell me who you are.
fatal: unable to auto-detect email address (got 'you@DESKTOP-XXXXXXX.(none)')
Mac は止まらないが、代わりに you@Taro-no-MacBook-Air.local のような架空のアドレスで記録されてしまう。これでは GitHub に送っても自分のアカウントに紐づかない。どちらの環境でも、コミットを始める前に登録しておくのが正解。

Claude Code に「コミットして」と頼んだ場合は、このエラーが表に出ないことがある。 未設定だと気づいて、その場限りの名前とメールを自分で決めてコミットしてしまう（2026-09-18 に Windows の実機で確認）。止まらない代わりに、自分が選んでいない値が記録に残る。先に登録しておけば、この迷いがなくなる。

メールアドレスを公開したくない場合は、GitHub が用意する noreply アドレス（12345678+ユーザー名@users.noreply.github.com）を使う手もある（コミットメールアドレスを設定する）。アカウント作成後にしか分からないので、その場合は4章まで進んでから git config --global user.email をやり直す。

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

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

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

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

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

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

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

3-2. ファイルを作る

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

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

右上の縦三点メニュー → ファイル（→ CDG 5-5）で README.md が作られていることを確認できる。

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

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

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

git init

これで .git/ という隠しフォルダができる。2章で「フォルダ＋履歴のセットをリポジトリと呼ぶ」と書いた、その履歴の実体がこれ。コミットの中身も設定も、すべてここに入る。.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 に「コミットして」と頼むだけでも同じことができる。「小さく変える → コミット」を4回くり返して、履歴を溜めていく（あとの 3-6 で戻すのに使う）。

1回目：ファイルを増やして、2つまとめてコミット

Web ページの実体を追加する。ここだけは git add を手で入力して、複数のファイルを一度にステージングする感覚をつかんでおく。

public/index.html として Hello World と表示するだけのシンプルなHTMLを作って。
README.md にもそのことを書いておいて

public/index.html が新しくでき、README.md も書き換わる。状態を見る：

git status

modified: README.md（変更された）と Untracked files: public/（まだ追跡されていない）の2つが出る。新しく作ったフォルダは中のファイルを1つずつ並べず public/ とまとめて表示される。

2つまとめてステージングしてコミット：

git add README.md public/index.html
git commit -m "Hello World のページを追加"

git add はスペース区切りでファイルを並べられる。全部まとめてよければ git add . でもよい（. は「このフォルダ以下すべて」の意味）。

1コミット＝1つのまとまり：ここでは「ページを足した」という1つの作業が public/index.html と README.md の2ファイルにまたがっている。こういうときはまとめて1コミットにする。逆に、関係のない変更が混ざっているときは git add で片方だけ選んで別々にコミットする。3-4 の「ステージングは次のコミットに含めるファイルを選ぶ操作」というのは、このためにある。

2回目：見た目を変えてコミット

ここからは Claude Code に任せる。

public/index.html を派手にして

コミットして

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

git add public/index.html
git commit -m "見た目を派手にする"

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

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

自分で直してもよい。縦三点メニュー → ファイル で README.md をクリックし、右上の </> ボタンで編集モードにして書き足す → 保存。どちらでも結果は同じ。

コミット

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

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

commit

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

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

3-6. 過去のことも覚えているアシスタント

ここまでで5つのコミットが溜まった。Git はそれを記録しているだけで、何も解釈してくれない。 読んで答えるのは Claude Code のほう。記録は Git、読み解きは AI という組み合わせにすると、「過去のことも覚えているアシスタント」に頼むように使える。

ここでは5つ頼んでみる。コマンドを正確に覚える必要はない。 「さっきの変更をなかったことにしたい」のように状況を言えば、Claude Code が適切なコマンドを選んで実行してくれる。

今日やったことをまとめてもらう

まず、履歴を読みやすい表で出してもらう：

変更履歴を表で見せて

コミット・日時・内容がこんな形で表に並ぶ。3-4 と 3-5 で作った5つのコミット（最初のコミット → Hello World のページ追加 → 見た目を派手に → 川柳追加 → 日付追加）がそのまま並んでいるのが分かる。

ここからがアシスタントらしいところ。表を読むのではなく、要約してもらう。

今日やったことを100文字ほどでまとめて

返ってくる要約は、履歴の刻み方で決まる。 3-5 で「小さく変える → コミット」を繰り返したので、「ページを作り、見た目を派手にして、川柳と日付を足した」のように中身のある文が返る。まとめて1回しかコミットしていなければ、「いろいろ変えた」しか出てこない。

コミットメッセージは Claude Code が変更内容から付けてくれるので、自分で書かなくても読める履歴になる。自分で決めたいときは「『川柳を追加』というメッセージでコミットして」のように頼めばよい。

参考までに、表や要約のもとになっている生の履歴も見ておく：

git log

コミットハッシュ・著者・日付・メッセージが時系列で並ぶ。

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

間違って消したファイルを戻す

いちど、本当に消してみる。Finder で README.md をゴミ箱に入れる。

間違って消しちゃった。戻して

ファイル名を言わなくても戻る。 何が消えたかは、記録と今のフォルダを見比べれば分かるため。

戻るのは、コミットしてあるものだけ。 一度もコミットしていないファイルを消した場合、Git には記録がないので取り戻せない（ゴミ箱や Time Machine を当たることになる）。

ゴミ箱に入れた直後なら、ゴミ箱から戻すほうが早い。 Claude Code がそちらを勧めることもある。ここで Git を使うのは、ゴミ箱を空にしたあとでも、別のパソコンからでも、コミットしてあれば戻せるため。

裏で動くのは git restore README.md。

前の状態に戻す

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

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

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

裏で動くのは戻す系のコマンド（git revert または git reset）。このとき、戻し方は2通りある。 Claude Code がどちらにするか聞いてくることもある。違いは 3-7 で説明する。

戻したのを取り消す

戻してみたものの、やっぱり前のほうがよかった、ということがある。

戻したのを取り消して

戻す操作そのものも記録されているので、戻す前の状態に帰ってこられる。「戻したら終わり」ではないと分かると、戻す操作が怖くなくなる。

履歴を書き換えたつもりでも、書き換えた記録がまだ残っている。

ただし万能ではない。戻せるのは 手元のリポジトリの中だけで、古い記録はいずれ Git が片付ける。そしてコミットしていない変更は、どうやっても戻せない。

裏で動くのは git reflog（操作そのものの履歴）と、そこから戻す操作。

昔と今を比べる

戻す前に、そもそも何が変わったのかを見たいことがある。

派手にする前と今で、何が変わった？

行単位で「どこがどう変わったか」が出る。戻す前に、見るだけで用が足りることは多い。

裏で動くのは git diff。

ほかにも頼めること

git add したファイルをステージから外す
直前のコミットメッセージや内容を直す
さっきの変更をなかったことにして、最後にコミットした状態に戻す

どれも状況を言えば通じる。「さっきのコミットメッセージが雑だったので書き直して」のように頼めばよい。

3-7. 戻し方は2通りある（履歴を残すか、消すか）

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

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

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

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

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

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

川柳を足す前のコミットまで巻き戻して。
川柳以降のコミットは履歴ごと消して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の右上の ︙（メニュー） → 翻訳 → 表示されたポップアップの ︙ → このサイトは翻訳しない。

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

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

Continue with Google
ユーザー名を設定して登録完了

Create account

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

4-2. Git のメールアドレスが GitHub と一致しているか確認する

2-2 で登録したメールアドレスが、いま作成した GitHub アカウントのものと一致しているか確認する：

git config --global user.email

同じならこの節はこれで終わり。違っていたら GitHub 側に合わせておく：

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

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

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

ここで変更した場合、3章で作ったコミットには変更前のアドレスが残ったままになる。練習用リポジトリなので気にしなくてよい。

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

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

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

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 にこう頼む：

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 に送る

補足: push で何が送られているか 送られるのは .git/（→ 3-3）に溜まったコミットと、そこに記録されたファイルの中身。フォルダをまるごとアップロードしているのではなく、GitHub 側がまだ持っていないコミットだけが渡る（ローカル固有の設定などは送られない）。GitHub のリポジトリページでファイル一覧が見えるのも、最新のコミットを展開して表示しているだけで、向こうに作業フォルダが置いてあるわけではない。そのため、Git に追跡させていないファイル（→ 6-3）は GitHub 上に存在しない。

5. 日々の運用

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

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

pushして

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

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

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

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

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

1回目：短文を足して push

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

プッシュして

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

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

push

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

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

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

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 は cli.github.com から新しい .msi を入れ直す）で更新する。

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 で作った別のリポジトリを使う。

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

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

注意点：

最初に表示されるのは、公開フォルダの直下にある index.html。git-test で作った HTML は public/ の中なので拾われず、代わりに README.md の内容がレンダリングされて表示される。Deploy from a branch で選べる Folder は / (root) と /docs の2つだけなので（公式ドキュメント）、public/index.html をトップにしたいならファイルをリポジトリ直下か docs/ に移す。任意のフォルダを公開フォルダにしたい場合は GitHub Actions を使う（→ GHA）
- このあたりは Cloudflare Pages のほうが素直で、public のような出力フォルダをそのまま指定できる（→ CGT）
あくまで静的サイト（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 を習慣づけてこまめに最新状態にしておくことで防ぎやすくなる。

6-11. 作業メモをリポジトリに残す

リポジトリに置けるのはコードだけではない。「なぜこの方式にしたのか」「何を調べたのか」も Markdown で一緒に置いておける。Claude Code は毎回ゼロから始まるので、経緯を残しておくと次のセッションでも読んでもらえる。GitHub 上ではそのまま Wiki のように読める（→ 作業メモと決定をリポジトリの中に残す）。

7. もっと詳しく

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

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

2026-05-24 (last updated: 2026-08-20) タツヲ (yto)

☕️ Vibecoding Notes を応援