Fork vs Clone in Git: What's the Difference?

A fork is a copy of someone else's repository made into your own account, so you can change it freely when you do not have permission to push to the original. A clone is a local copy of any repository on your own machine, so you can actually work with the files. They are not alternatives to each other: when you contribute to a project you cannot push to, you fork it on GitHub, then clone your fork to your computer. You do both.

That is the whole answer. The rest of this article unpacks why the distinction trips people up, and walks through the fork-and-pull-request flow step by step.

Fork vs clone at a glance

The quickest way to see the difference is to look at where each copy lives and who controls it.

The short version: forking is about ownership and permission, cloning is about getting the code onto your computer. One is a feature of the host; the other is a core Git command.

What cloning does

git clone downloads a complete copy of a repository, with its entire history, onto your machine. After it finishes you have every commit, every branch, and a .git directory, plus a remote called origin pointing back at where you cloned from.

git clone https://github.com/some-org/some-project.git
cd some-project
git remote -v

That last command shows the remote that was set up for you:

origin  https://github.com/some-org/some-project.git (fetch)
origin  https://github.com/some-org/some-project.git (push)

The catch is the push line. The clone records that URL as a push target, but whether your push is actually accepted depends entirely on the permissions on the server. If you do not have write access to some-org/some-project, your push is rejected:

remote: Permission to some-org/some-project.git denied to your-username.
fatal: unable to access 'https://github.com/some-org/some-project.git/': The requested URL returned error: 403

Cloning never grants permission. It only copies. That is the single most common point of confusion, and it is the reason forks exist. If you want the longer treatment of pulling an existing project down to start working, see my guide on how to start working on an existing Git project.

What forking does

Forking is a GitHub (or GitLab, or Bitbucket) feature, not a Git command. You click Fork in the web UI and the platform makes a server-side copy of the entire repository under your own account. So some-org/some-project becomes your-username/some-project.

Because the fork lives in your account, you own it. You can push to it freely, create branches, rewrite whatever you like, all without touching the original. GitHub also remembers where your fork came from, which it calls the upstream parent, and that link is what makes the pull-request flow possible later.

A fork on its own is still just a copy sitting on the server. To actually edit the code you still have to clone it down to your machine. This is why you do both: fork to get a copy you own, clone to get that copy onto your computer.

When to use which

The decision comes down to one question: do you have push access to the repository you want to work with?

• You have push access (it is your repo, or you are a collaborator on a team repo). Just git clone it and push your branches directly. No fork needed. This is the everyday case for your own projects and your team's projects.
• You do not have push access (a public open-source project, someone else's repo). Fork it first so you have a copy you own, then clone the fork. This is the standard open-source contribution path.

If you only want to read the code, run it, or experiment locally without ever sending changes back, a plain clone is enough. You do not need a fork to look around. You need a fork only when you intend to contribute changes back and you lack write access to the original.

The fork-and-pull-request workflow

This is the model nearly every open-source project on GitHub uses. Here it is end to end.

1. Fork the repository. On the project's GitHub page, click Fork. GitHub creates your-username/the-project in your account.

2. Clone your fork. Copy the code from your fork (not the original) down to your machine:

git clone https://github.com/your-username/the-project.git
cd the-project

If you are setting up SSH for this, my notes on adding an SSH key to GitHub and on choosing between SSH and HTTPS remotes cover the auth side.

3. Add the original as an upstream remote. Your clone only knows about origin (your fork). Add a second remote pointing at the project you forked from, so you can pull in their latest changes later. If you hit a snag here, my notes on how Git remotes work and how to manage them cover the common errors:

git remote add upstream https://github.com/some-org/the-project.git
git remote -v

origin    https://github.com/your-username/the-project.git (fetch)
origin    https://github.com/your-username/the-project.git (push)
upstream  https://github.com/some-org/the-project.git (fetch)
upstream  https://github.com/some-org/the-project.git (push)

4. Make a branch and your changes. Never work directly on main. Branch off, make your edits, and commit:

git checkout -b fix-typo-in-readme
# edit files
git add README.md
git commit -m "Fix typo in installation section"

If branching is new to you, I wrote a beginner's explanation of Git branching, and Git commit message best practices covers writing that commit line well. That git add step is itself worth understanding; I explain what the staging area is actually doing before a commit.

5. Push the branch to your fork. It goes to origin, which is your fork, so you have permission:

git push origin fix-typo-in-readme

6. Open a pull request. Back on GitHub, open a pull request from your branch on your fork into the original project's main branch. The maintainers review it, and if they like it, they merge it. The full mechanics are in how to create a pull request.

That is the entire loop. You never needed push access to the original repo, because your changes flowed through your own fork and arrived as a pull request the maintainers chose to merge.

Keeping your fork up to date

The day after you fork, the original project keeps moving and your fork goes stale. That is what the upstream remote from step 3 is for. To pull in the latest changes from the original:

git fetch upstream
git checkout main
git merge upstream/main
git push origin main

This fetches the original project's commits, merges its main into your local main, and pushes the result back to your fork so the fork matches upstream again. I cover this in depth, including the rebase variant and how to avoid conflicts, in how to sync a fork with the upstream repo. If you are unsure which to reach for here, the difference between merging and rebasing breaks down the trade-off. If the fetch and merge distinction here is fuzzy, my write-up on git pull vs git fetch explains why fetching first and merging deliberately is the safer habit.

Common confusions

"Forking creates a copy on my computer." No. Forking creates a copy on the server, in your account. You still have to clone to get it onto your machine.

"I cloned it, so why can't I push?" Cloning copies the code and records a push URL, but it does not grant permission. If you lack write access, the push is rejected with a 403. Fork first, then clone the fork.

"Do I need a fork for my own projects?" No. For repos you own or have collaborator access to, clone directly and push your branches. Forks are for contributing to projects you cannot push to.

"Can I delete my fork after the PR is merged?" Yes. Once your pull request is merged into the original, the fork has served its purpose and you can delete it safely. The merged commits live in the original repo now.

New to Git overall? Start with my Git for beginners guide, which lays out the core ideas in order before you get to forks and pull requests.