定期実行・自動化 2026年9月29日 8分で読めます

GitHubのフォークとクローンの違いを手を動かして理解した

GitHubのフォークとクローンの違いを手を動かして理解した

GitHubのフォークとクローンの違い、説明を読んでもピンと来なかったことはありませんか？

私はまさにそうでした。「フォークはコピー」「クローンもコピー」。どちらもコピーなら、何が違うの？と。

この記事では、非エンジニアの私がClaude Codeを使い、手元の練習用リポジトリで実際に動かして、ようやく違いが腑に落ちた過程をまとめます。最後に、読者の方がそのままClaude Codeに貼れるプロンプトも載せています。

—

GitHubのフォークとクローンの違いは「コピー先」

一言で言うと、違いはコピーする場所です。

**フォーク（fork）**：他人のリポジトリを、**GitHub上の自分のアカウント**にコピーする
**クローン（clone）**：GitHub上のリポジトリを、**自分のPC**にコピーする

実際の流れでは、この2つを組み合わせて使います。

1. 他人のリポジトリをフォークする（GitHub上に自分用のコピーができる）

2. その自分用コピーをクローンする（PCで編集できるようになる）

3. 編集したらフォークにpushし、元のリポジトリにPull Requestを送る

GitHub公式ドキュメント（2026-09-29確認）でも、フォークは「元のリポジトリとコードや公開設定を共有する新しいリポジトリ」と説明されています。ここに「GitHub上に作られる」という点が隠れていたのが、私が混乱した原因でした。

—

説明を読んでも理解できなかった理由

私が最初につまずいたのは、「どちらもコピー」という言葉だけで覚えようとしたことです。

図解を見てその場ではわかった気になっても、翌日には「どっちがどっちだっけ」に戻っていました。

いま振り返ると、リポジトリが3つ登場することを意識していなかったのが原因だと思います。

呼び名	置き場所	持ち主
元のリポジトリ（upstream）	GitHub	他人
フォーク（origin）	GitHub	自分
クローン（作業用）	自分のPC	自分

「コピー」が2回起きて、合計3つになる。これが見えた瞬間に、急に整理がつきました。

—

Claude Codeと練習用リポジトリで動かしてみた

本物のGitHubで他人のリポジトリをフォークすると、相手のリポジトリにフォーク数として残ります。練習のたびにそれをするのは気が引けたので、今回はPCの中だけで3つのリポジトリを再現してClaude Codeに動かしてもらいました。

作ったのは次の3つです。

`original`：元のリポジトリ役（他人のプロジェクトのつもり）
`fork.git`：フォーク役（GitHub上の自分用コピーのつもり）
`mywork`：クローン（PCで作業する場所）

※本物のフォークはGitHub上の操作です。ここではGitHubを使わず、`git clone –bare` で「サーバー上のコピー」の代わりを作りました。あくまで仕組みを体感するための再現です。

私の環境はmacOS、Git 2.33.0です（2026-09-29時点）。Windowsや別バージョンでは表示が少し違う場合があります。

発見1：クローンした時点では「origin」しか知らない

`mywork` で `git remote -v` を実行すると、表示されたのは `origin`（＝フォーク役）だけでした。

つまり、クローンしたPCのリポジトリは、自分のフォークのことしか知らない。元のリポジトリの存在はまだ登録されていません。

そこで元のリポジトリを `upstream` という名前で登録すると、`origin` と `upstream` の2つが並びました。「3つのリポジトリがつながった」と目で確認できたのが大きかったです。

発見2：元が更新されても、フォークは勝手に追いつかない

次に、`original` 側に新しいコミットを1つ追加しました。

この時点で `mywork` には、その更新は入っていません。`git fetch upstream` で取得して初めて、元の更新が見えるようになりました。さらに `git merge upstream/main` で手元のmainに取り込み、`git push origin main` したところで、ようやくフォーク役にも反映されました。

「フォークは放っておくと古くなる」。読んでいたはずなのに、動かして初めて実感しました。

ちなみに本物のGitHubなら、フォークのページにある「Sync fork」ボタンや、GitHub CLIの `gh repo sync` でも同期できると公式ドキュメントに書かれています（2026-09-29確認）。こちらはまだ試せていません。

—

フォークとクローン、どちらを使えばいい？

使い分けは、次の基準で考えるとシンプルでした。

**自分のリポジトリ、または書き込み権限がある** → クローンだけでOK
**他人のリポジトリで、書き込み権限がない** → フォークしてからクローン
**ただ中身を見たい・手元で動かしたいだけ** → クローンだけでOK

自分用ツールの管理ならクローンだけで足りることが多く、フォークが必要になるのは他人のプロジェクトに修正を提案したいときが中心です。

なお、GitHub CLI（`gh`）を使っている場合は、`gh repo fork 持ち主/リポジトリ名 –clone` でフォークとクローンを一度に行えます。公式マニュアルによると、このときフォークが `origin`、元のリポジトリが `upstream` として自動で登録されます（2026-09-29確認）。今回はGitHub上に実際のフォークを作らなかったので、このコマンドは試していません。

—

読者向けプロンプト：練習用リポジトリで違いを体験する

私が使った流れを、そのままClaude Codeに頼めるプロンプトにしました。GitHubには一切アクセスせず、PCの中だけで完結します。


GitHubのフォークとクローンの違いを体験したいです。
GitHubにはアクセスせず、PCの中だけで次の3つを再現してください。

- 作業フォルダ: 現在のフォルダの下に新しく fork-practice フォルダを作り、その中だけで作業する
- original: 元のリポジトリ役（READMEを1つコミット）
- fork.git: フォーク役（git clone --bare で original をコピー）
- mywork: fork.git をクローンした作業用リポジトリ

そのあと、次を順番に実行し、各ステップで何が起きたかを初心者向けに1〜2文で説明してください。
1. mywork で git remote -v を表示する
2. original を upstream として登録し、もう一度 git remote -v を表示する
3. original に新しいコミットを1つ追加する
4. mywork で git fetch upstream し、fetch前後で git log --oneline --all の表示がどう変わるかを見せる

実行前に、作成するフォルダとファイルの一覧を表示してください。
fork-practice フォルダがすでに存在する場合は、中身を削除・上書きせずに私に確認してください。
不明点は推測せず、確認事項として列挙してください。

ポイントは、作業フォルダを限定していることです。既存のプロジェクトの中で試すと、remoteの設定を誤って変えてしまう心配があるためです。

—

実際のフォークでupstreamを設定するときのプロンプト

GitHub上ですでにフォークしてクローン済みの場合は、次のようなプロンプトで「元のリポジトリの更新を取り込む」準備ができます。


このリポジトリは、GitHubでフォークしたものをクローンしたものです。
元のリポジトリの最新の変更を取り込みたいです。

- 対象: 現在のフォルダのリポジトリのみ
- 元のリポジトリのURL: https://github.com/OWNER/REPO.git

まず git remote -v で現在の設定を表示し、upstream が未登録なら登録方法を提案してください。
merge、rebase、push などの変更を実行する前に、対象ブランチ、取り込まれるコミットの一覧、差分、影響範囲を表示してください。私が確認してから実行してください。
force push は行わないでください。
不明点は推測せず、確認事項として列挙してください。

`OWNER/REPO` の部分は、フォーク元のリポジトリに置き換えてください。

—