Forking Projects

Forking is one of GitHub's most important features and the mechanism that makes open source contribution possible at scale. It allows anyone to take a copy of a project they do not own, work on it freely, and propose their changes back to the original — all without needing write access to the source repository.

What a Fork Is

A fork is a complete copy of a repository that lives under your own GitHub account. It is linked to the original repository — GitHub calls the original the upstream — but it belongs entirely to you. You have full write access to your fork. You can push branches, make changes, and organise your work however you like without affecting the original project at all.

The fork maintains a connection to its upstream, which means:

• GitHub can tell you when your fork is behind the original.
• You can open a pull request from your fork back to the upstream at any time.
• You can pull in new changes from the upstream to keep your fork current.

Fork vs. Clone — The Distinction

These two operations are related but serve different purposes:

In practice, you almost always do both: fork the repository on GitHub to get your own remote copy, then clone your fork to your local machine to do the actual work.

The Historical Meaning of "Fork"

Before GitHub, the word "fork" carried a negative connotation in open source — it meant a group of developers had taken a project in a different direction, creating a competing project and splitting the community. Projects like LibreOffice (forked from OpenOffice) or MariaDB (forked from MySQL) are examples of this kind of fork.

On GitHub, "fork" means something much more routine. It simply creates a copy in your namespace so you can propose changes. The vast majority of forks are never intended to become independent competing projects — they are the first step in a contribution.

How to Fork a Repository

Forking on GitHub takes one click:

1. Navigate to the repository you want to fork.
2. Click the Fork button in the top-right corner of the page.
3. Choose the account or organisation to fork into (if you belong to multiple).
4. GitHub creates your fork in seconds and redirects you to it.

Your fork is now at:

https://github.com/<your-username>/<repository-name>

It is a full, independent copy of the original — including all its branches, commits, and history — at the point in time you forked it.

Working with Your Fork Locally

Once you have a fork, clone it to your local machine:

git clone git@github.com:your-username/repository-name.git
cd repository-name

At this point your local repository has one remote — origin — pointing to your fork. To also track the original repository, add it as a second remote conventionally called upstream:

git remote add upstream https://github.com/original-owner/repository-name.git

Verify your remotes:

git remote -v

origin    git@github.com:your-username/repository-name.git (fetch)
origin    git@github.com:your-username/repository-name.git (push)
upstream  https://github.com/original-owner/repository-name.git (fetch)
upstream  https://github.com/original-owner/repository-name.git (push)

Now you have two remotes:

• origin — your fork, where you push your work.
• upstream — the original repository, where you pull in new changes.

Keeping Your Fork Up to Date

The original repository continues to evolve after you fork it. Your fork does not update automatically — you have to pull in the upstream changes manually.

# Fetch the latest changes from the original repository
git fetch upstream

# Switch to your main branch
git switch main

# Merge the upstream changes into your local main
git merge upstream/main

# Push the updated main to your fork on GitHub
git push origin main

After this, your fork's main branch matches the upstream's main — your fork is back in sync.

Keeping your fork current is important before opening a pull request. If your fork is significantly behind the upstream, your changes are more likely to conflict with recent work in the original project.

When to Use a Fork

The key rule: if you have write access to the repository, use a branch. If you don't, fork.

The Fork Network

GitHub tracks forks and their relationships to each other. On the original repository's page, you can see how many forks exist and browse them. On your fork, GitHub shows you how far ahead or behind the upstream your fork is:

This branch is 3 commits behind original-owner:main.

GitHub also provides a Sync fork button on the repository page that updates your fork's default branch with a click — though doing it via the command line gives you more control.

Forking Without Intending to Contribute

Not every fork is a contribution. Developers also fork repositories to:

• Study the code — explore and experiment without worrying about breaking the original.
• Use a project as a starting point — take a template, boilerplate, or starter project and build something new from it.
• Archive a project — preserve a copy of a repository in case the original is deleted or made private.

All of these are valid and common uses of forking.

Summary