先に要点
- いちばんの違いは 「どこにコピーを作るか」。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 は「コピーを作る場所」が違います。
- 2
clone(ローカルにコピー)
GitHub上のリポジトリ → 自分のPC(手元)にダウンロードされる。ローカルの複製。git 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 する権限があるかの一点です。
forkが要るか、cloneだけでよいか
cloneだけでよい
自分のリポジトリや、書き込み権限のあるチームのリポジトリ。
- 自分が作ったリポジトリを手元で作業する
- 会社/チームでメンバーとして招待され、直接pushできる
- ブランチを切ってpushし、そのままPull Requestを出せる
- forkは不要。git cloneして作業を始める
こんな人向け自分・所属チームのリポジトリ
forkしてからcloneする
他人の公開リポジトリ(OSSなど)に変更を提案したいとき。
- 元リポジトリへ直接pushする権限が無い
- まずforkして自分のアカウントにコピーを作る
- そのforkをcloneして手元で編集・push
- 元リポジトリへPull Requestで変更を提案する
こんな人向けOSSへの貢献・外部リポジトリへの提案
ポイントは、「単に手元で動かしたい・読みたい」だけなら clone で十分だということです。fork が要るのは、直接 push できない他人のリポジトリに、自分のコピーを経由して変更を提案したいときです。逆に、自分やチームの書き込み権限があるリポジトリを無闇に fork すると、かえって管理が煩雑になります。
OSS貢献の定番フロー(fork → clone → pull request)
fork と clone の関係がいちばんはっきりするのが、OSSに貢献するときの流れです。GitHub公式も、fork の変更はPull Requestで元(upstream)へマージできる、と説明しています。
外部リポジトリへ貢献する手順
- 1forkする(GitHub上)
貢献したいリポジトリのページでForkし、自分のアカウントにコピーを作る。ここはGitHubの操作でコマンドは使わない。
- 2cloneする(ローカルへ)
作ったforkのURLを git clone で手元に落とす。これで自分のPCで編集できるようになる。
- 3ブランチを切って編集・コミット
作業用ブランチを作り、変更してコミット。mainに直接積まず、テーマごとにブランチを分けるのが定石。
- 4自分のforkにpush
コミットを自分のfork(origin)へpushする。この時点では元リポジトリには影響しない。
- 5Pull Requestを送る
自分のforkから元リポジトリ(upstream)へPull Requestを作成し、変更をレビュー・マージしてもらう。
この流れの中で、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