先に要点
- いちばんの違いは 「どこにコピーを作るか」。fork は GitHub 上の自分のアカウントにコピーを作る、clone はリポジトリを手元のPC(ローカル)に複製する。作られる場所が違います。
- そもそも fork は GitHub / GitLab などの機能で、git のコマンドではありません。
git forkというコマンドは存在しません。一方 clone はgit cloneという git 標準のコマンドです。 - 書き込み権限があるリポジトリなら clone だけでOK。他人のリポジトリに変更を提案したい(権限が無い)ときに forkを使い、自分のコピーを経由して プルリクエストを送ります。
- OSS貢献の定番は fork(GitHub) → clone(ローカル) → ブランチで編集 → 自分のforkにpush → 元リポジトリへPull Requestという流れです。
- fork した自分のコピーは元リポジトリ(upstream)と つながりが残るため、PRで変更を還元でき、元の更新を取り込んで同期もできます。単なる clone は手元の複製で、その連携経路は持ちません。
fork と clone、どっちも「コピー」でしょ？何が違うの？ ── Git を使い始めると必ずぶつかる疑問です。どちらもリポジトリを複製する操作に見えますが、コピーが作られる場所も、そもそもの仕組みの層も違います。ここを取り違えると、「権限が無くて push できない」「PRの送り先が分からない」と詰まります。
この記事では、両者の違いを 「どこにコピーが作られるか」→ そもそも fork は git ではない → clone だけでよい場面 / fork が要る場面 → OSS貢献の流れ → origin と upstream の整理の順で実務目線で整理します。定義はGitHub公式のAbout forksを確認しながらまとめています。Git そのものが曖昧ならGitの用語集もどうぞ。
いちばんの違い:どこにコピーを作るか
まず結論です。fork と clone は「コピーを作る場所」が違います。
- fork ── GitHub 上で、元リポジトリのコピーを自分のアカウントの下に作る。あくまで サーバー(GitHub)側での複製で、手元にはまだ何も落ちてきません。fork したコピーは自分専用で、独自にブランチやコミットを積めます。
- clone ── GitHub 上のリポジトリを、自分のPCに丸ごとダウンロードする。ローカル(手元)側への複製で、ここで初めてコードをエディタで開いて編集できます。実行は
git clone リポジトリのURL。
つまり、fork は「GitHub上に自分用の出発点を作る」、clone は「その出発点を手元に持ってくる」という、別々のステップです。多くのOSS貢献では、この2つを順番に両方やります。
そもそも fork は git の機能ではない(ここが重要)
もう一つの本質的な違いがこれです。fork は GitHub や GitLab などのホスティングサービスが提供する機能であって、git 本体のコマンドではありません。GitHub公式も fork を「元(upstream)リポジトリとコードや公開設定を共有する新しいリポジトリ」と説明し、あくまで GitHub 上の操作として扱っています。
| 観点 | fork | clone |
|---|---|---|
| 正体 | GitHub / GitLab の機能(概念) | git の標準コマンド |
| コマンド | 無し(画面のForkボタン等で操作) | git clone URL |
| コピー先 | 自分のGitHubアカウント(サーバー側) | 自分のPC(ローカル) |
| 元との関係 | upstreamとつながり、PRで還元できる | originとして参照(手元の複製) |
| 主な目的 | 権限の無いリポジトリに変更を提案する起点 | 手元でコードを取得して作業する |
| 独自のIssue/PR | 持つ(forkは独立したリポジトリ) | 持たない(ローカルの作業コピー) |
だから「fork と clone、どちらの git コマンドを使う？」という問い自体が少しずれています。fork は GitHub の画面(またはAPI)で行う操作、clone は git のコマンド、と層が違うものとして捉えると混乱しません。
clone だけでよい場面 / fork が要る場面
実務で迷うのは「fork すべきか、clone だけでいいか」です。判断軸は そのリポジトリに直接 push する権限があるかの一点です。
ポイントは、「単に手元で動かしたい・読みたい」だけなら clone で十分だということです。fork が要るのは、直接 push できない他人のリポジトリに、自分のコピーを経由して変更を提案したいときです。逆に、自分やチームの書き込み権限があるリポジトリを無闇に fork すると、かえって管理が煩雑になります。
OSS貢献の定番フロー(fork → clone → pull request)
fork と clone の関係がいちばんはっきりするのが、OSSに貢献するときの流れです。GitHub公式も、fork の変更はPull Requestで元(upstream)へマージできる、と説明しています。
この流れの中で、fork は最初の1回(GitHub上)、clone はそれを手元に持ってくる1回だけ登場します。あとの編集・コミット・pushは通常の git 操作です。「fork = 貢献の入口を用意する」「clone = 手元で作業できるようにする」と役割で覚えると、順番も自然に頭に入ります。
origin と upstream の整理(forkワークフローで混乱しないために)
fork を使うと、リモートが2つ登場して混乱しがちなので整理します。
origin
自分がcloneしてきた先。forkワークフローでは「自分のfork」を指す。push先はここ。
upstream
元の(本家)リポジトリ。ここへ直接pushはできない。Pull Requestの送り先であり、最新を取り込む元。
forkを最新に保つ
本家が進んだら、upstreamの変更を取り込んで自分のforkを同期する。放置すると差が開いてPRが衝突しやすい。
自分のリポジトリを clone しただけなら、リモートは origin の1つだけで足ります。fork ワークフローのときだけ、本家を upstream として追加で登録し、push は origin(自分のfork)へ、最新の取り込みは upstream から、と使い分けるのが定番です。
Gitのforkとcloneに関するよくある質問
fork と clone の一番の違いは何ですか？
コピーが作られる場所です。fork は GitHub 上の自分のアカウントにコピーを作る機能、clone はリポジトリを手元のPCに複製する git コマンドです。fork はサーバー側、clone はローカル側の複製で、層も目的も異なります。
git fork というコマンドはありますか？
ありません。fork は GitHub / GitLab などのホスティングサービスの機能で、画面のForkボタンやAPIで行います。git 標準のコマンドは git clone のほうで、fork に相当する git コマンドは存在しません。
fork せずに clone だけではダメですか？
自分やチームの書き込み権限があるリポジトリなら、clone だけで十分です。ブランチを切って push し、そのままPull Requestを出せます。fork が要るのは、直接 push できない他人のリポジトリに変更を提案したいときだけです。
fork したリポジトリは元と連動しますか？
自動では同期しません。fork は独立したリポジトリとして独自のブランチ・Issue・Pull Requestを持ちますが、元(upstream)とのつながりは残るため、Pull Requestで変更を還元したり、upstreamの更新を取り込んで手動で同期したりできます。放置すると差が開くので、こまめに同期するのがおすすめです。
clone した後に fork が必要になったらどうしますか？
先に自分のPCへ clone してしまい、後から fork が必要だと気づくこともあります。その場合は GitHub で fork を作り、手元リポジトリの origin を自分のfork に付け替え、本家を upstream として追加すれば、そのまま fork ワークフローに移れます。作業内容を作り直す必要はありません。
download(ZIPダウンロード)と clone は違いますか？
違います。ZIPダウンロードはその時点のファイル一式を落とすだけで、コミット履歴もgitのつながりもありません。clone は履歴を含むリポジトリ全体を複製し、そのまま commit や push ができます。あとで変更を管理するなら clone を使います。
まとめ
Gitの fork と clone は、どちらも「コピー」ですが、作られる場所と仕組みの層が違います。fork は GitHub 上の自分のアカウントにコピーを作る機能(gitコマンドではない)、clone はリポジトリを手元のPCに複製する git コマンドです。判断は「そのリポジトリに直接 push できるか」で、権限があれば clone だけ、無ければ fork してから clone。OSS貢献では fork → clone → ブランチ編集 → push → Pull Request の流れが定番で、origin(自分のfork)と upstream(本家)を使い分ければ迷いません。clone した後にリモートの最新を取り込む操作でつまずくなら、git pullとgit fetchの違いもあわせて読むと、取得と取り込みの切り分けが整理できます。
参考リンク
- GitHub Docs: About forks(forkの定義とワークフロー)
- Git 公式: git clone ドキュメント
- 用語集: Git