Git Clone vs Fork - What's the Difference?

This is something I’ve sort of understood but never quite got around to stamp out the differences, so I felt like sharing it!

Lets look at the key differences between Git clone and Git(Hubs) fork operations, and when to use which one.

Git Clone

Cloning creates a local copy of a repository. When running git clone, you get:

  • The entire .git directory
  • All branches and history
  • A working copy of the files
  • Remote tracking to the original repo (origin)

Example:

git clone https://github.com/user/repo
cd repo
git remote -v # Shows origin pointing to source

GitHub Fork

Forking is a GitHub feature (not Git) that creates your own copy of a repo on GitHub. Key points:

  • Lives on GitHub under your account
  • Independent from the original repo
  • Enables pull request workflow
  • Can sync with original (upstream) repo

Typical fork workflow:

# 1. Fork via GitHub UI
# 2. Clone your fork
git clone https://github.com/YOUR-USERNAME/repo
# 3. Add upstream remote
git remote add upstream https://github.com/ORIGINAL-OWNER/repo
# 4. Create branch and work
git checkout -b feature-branch

When to Clone

Use clone when:

  • You have write access to the repo OR
  • You just need a local copy to work with
  • You’re doing internal development
  • You don’t plan to contribute back but just want to run the code locally

When to Fork

Fork when:

  • Contributing to open source projects
  • You need your own version of a project
  • You don’t have write access to original repo
  • You want to propose changes via pull requests

Keeping Forks Updated

To sync your fork with upstream:

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

Key Differences Between Forking and Cloning

Here’s a breakdown of the technical and practical differences:

Aspect Forking Cloning
Scope Creates a copy of the repository on GitHub under your account. Creates a local copy of a repository on your machine.
Location Server-side (on GitHub). Local (on your computer).
Ownership You own the fork and have full control over it. You don’t own the repository; you just have a local copy.
Collaboration Designed for contributing to projects via pull requests. Primarily for local development or direct pushes (if you have access).
Upstream Relationship Forked repo is independent but can sync with the original via remotes. Cloned repo is tied to the original remote (origin) unless reconfigured.
Use Case Ideal for contributing to open-source projects or maintaining a derivative. Ideal for local development, testing, or private work.
Git Command Not a Git command; it’s a GitHub feature. More on this below on using the GitHub CLI! git clone <url> is a native Git command.

Using GitHub CLI

The GitHub CLI (gh) makes working with forks and clones even easier:

# Fork and clone in one command
gh repo fork user/repo --clone=true

# Just fork (no clone)
gh repo fork user/repo

# Clone your existing fork
gh repo clone YOUR-USERNAME/repo

# Create PR from your fork
gh pr create --base main --head YOUR-USERNAME:feature-branch

Pro tip: gh repo fork automatically sets up the upstream remote for you, saving the manual git remote add upstream step.

Installing the GitHub CLI 

# macos
brew install gh
# windows
winget install -e --id GitHub.cli -s winget
# linux - thanks -> https://dev.to/raulpenate/begginers-guide-installing-and-using-github-cli-30ka

# Arch
sudo pacman -S github-cli

# Debian, Ubuntu Linux, Raspberry Pi OS (apt)
(type -p wget >/dev/null || (sudo apt update && sudo apt-get install wget -y)) \
&& sudo mkdir -p -m 755 /etc/apt/keyrings \
&& wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
&& sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
&& sudo apt update \
&& sudo apt install gh -y
# Upgrade
sudo apt update
sudo apt install gh

# Fedora, CentOS, Red Hat Enterprise Linux (dnf)
sudo dnf install 'dnf-command(config-manager)'
sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf install gh --repo gh-cli
#Alternatively, install from the community repository:
sudo dnf install gh
#Upgrade
sudo dnf update gh

# openSUSE/SUSE Linux (zypper)
sudo zypper addrepo https://cli.github.com/packages/rpm/gh-cli.repo
sudo zypper ref
sudo zypper install gh
# Upgrade
sudo zypper ref
sudo zypper update gh

Common Fork Workflow

Here’s a typical workflow I use:

# Fork and clone
gh repo fork original-owner/repo --clone=true

# Create feature branch
git checkout -b my-feature

# Make changes, then commit
git add .
git commit -m "feat: add awesome feature"

# Push to fork
git push -u origin my-feature

# Create PR using GitHub CLI
gh pr create

Closing Thoughts

Both forking and cloning use Git’s object model (blobs, trees, commits), but:

  • Clone: Local copy of Git objects
  • Fork: Server-side copy with independent Git refs

The main difference is where the copy lives and how you can interact with the original repo.

Also, when cloning a repo, be aware of how you’ve authenticated. If you clone using SSH, you’ll need to add the SSH key to your GitHub account.

If you clone using HTTPS, you’ll need to enter your GitHub username and password.

I highly recommend using SSH or the GitHub CLI to clone repos - it’s much easier once you’ve set it up.

Happy Cloning and Forking!