Fork and Clone

In modern software development, the terms fork and clone describe two related but fundamentally different operations. Both involve making a copy of a repository, yet they operate at different levels and solve different problems.

A fork is a server-side feature offered by hosting platforms such as GitHub and GitLab. It creates a new remote repository under your account, linked to the original project, known as the upstream repository. A fork gives you full control over your copy: you can create branches, change settings, delete content, or make the repository private without affecting the original.

By contrast, cloning is a local Git operation performed with git clone. It downloads a remote repository—including its files, commit history, branches, and tags—to your computer. Once cloned, the repository becomes a local working environment where you can edit code, run tests, inspect history, and create commits even without an internet connection.

The distinction can be summarized simply: forking creates another remote repository; cloning creates a local repository.

How Forking Works

When you fork a repository on GitHub, the platform duplicates the project’s Git data within your own account. Your new repository may initially contain the same default branch, tags, and commit history as the upstream project, depending on the platform and repository configuration.

The fork does not grant you write access to the original repository. Instead, it gives you a safe space where you can prepare changes independently. Once your work is ready, you can open a pull request from your fork to the upstream project and ask the maintainers to review it.

Forks are especially useful when:

• You want to contribute to a project you cannot push to directly.
• You need a private or independently managed copy for experimentation.
• You want to build a customized version without altering the original project.
• Your team needs to maintain changes that may later be proposed upstream.

A fork does not synchronize automatically with its upstream repository. Updating it is therefore an explicit part of the collaboration workflow.

How Cloning Works

Cloning is performed from the command line or a Git client:

git clone https://github.com/owner/project.git
cd project

The command downloads the repository’s tracked files and Git history. It also configures the source repository as a remote named origin. This naming convention lets you run familiar commands such as:

git fetch origin
git push origin main

Because the clone exists on your machine, you can inspect previous revisions, compare branches, run builds, and commit changes without maintaining a persistent network connection. You only need connectivity when fetching new data or publishing commits.

Cloning is not limited to forks. You can clone an upstream repository directly, clone your own fork, or clone any repository you have permission to read.

A Standard Open-Source Workflow

Fork and clone are most often used together when contributing to an open-source project.

1. Fork the repository

Open the project on GitHub or GitLab and select Fork. The platform creates a copy under your account, for example:

upstream: original-owner/project
fork:    your-username/project

2. Clone your fork

Download your remote copy to your local development machine:

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

The local repository’s origin remote now points to your fork.

3. Add the upstream repository

To retrieve changes from the original project, add it as another remote:

git remote add upstream https://github.com/original-owner/project.git
git remote -v

You should now see both remotes:

origin    https://github.com/your-username/project.git
upstream  https://github.com/original-owner/project.git

4. Create a feature branch

Work on a dedicated branch rather than modifying the default branch directly:

git switch -c feature/new-component

5. Commit and push your changes

After editing the code, stage and commit the files:

git add .
git commit -m "Add new component"
git push origin feature/new-component

This publishes the branch to your fork, not to the upstream repository.

6. Open a pull request

Return to the hosting platform and open a pull request from your-username:feature/new-component to the upstream project’s default branch. Maintainers can then review the changes, request revisions, test the code, and merge the contribution if it is accepted.

Keeping a Fork Up to Date

Because forks are independent repositories, they do not receive upstream commits automatically. You can update your local copy with:

git fetch upstream

To incorporate upstream changes into your local default branch, switch to it and merge or rebase as appropriate:

git switch main
git merge --ff-only upstream/main

If the update can be applied cleanly, the fast-forward merge simply advances your local branch. Otherwise, you can rebase your feature branch onto the updated upstream branch:

git rebase upstream/main

After resolving any conflicts and verifying the result, push the updated branch back to your fork:

git push origin feature/new-component

If the branch has already been pushed and its history was rewritten, use:

git push --force-with-lease origin feature/new-component

The --force-with-lease option is safer than an unconditional force push because it refuses to overwrite remote changes that your local repository has not seen.

When a Fork May Not Be Necessary

A fork is not required in every Git workflow. If you already have push access to a shared repository, you can clone it directly and push your work to an appropriate branch:

git clone https://github.com/company/project.git
cd project
git switch -c feature/improvement

This is common in internal development teams, where every contributor has permission to create branches in the same remote repository. Forking remains valuable when direct write access is unavailable or when you need a separately owned copy.

The Practical Distinction

Think of the two operations as complementary layers:

• A fork solves the problem of ownership and publishing. It provides a remote repository that you control and can use as the source for a pull request.
• A clone solves the problem of local development. It provides the working files and complete Git history on your machine.

Understanding this difference prevents a common misconception: cloning a repository does not create a fork, and forking a repository does not place its files on your computer. In most open-source contributions, both operations are necessary—you fork on the server, clone the fork locally, add the upstream repository, and then move changes through the normal branch, commit, push, and pull-request workflow.