Forking vs. cloning a GitHub repository

Both actions get a copy of a repository onto your own machine or account, and beginners mix them up constantly because of that overlap. The difference is about ownership and where the copy lives.

Cloning: a local copy of any repository

git clone downloads a full copy of a repository, history included, to your own computer. You can clone any public repository, including ones you have no permission to modify. Cloning creates no new copy on GitHub itself; it is purely local.

git clone https://github.com/some-user/some-repo.git

Clone when you want to run a project locally, read its code, or, if you have push access, contribute directly to it.

Forking: your own copy on GitHub

A fork creates a full copy of a repository under your own GitHub account, alongside the original. It lives on GitHub, not just on your machine. Click “Fork” on a repository’s page, and GitHub creates that copy for you in seconds, linked back to the original as its upstream source.

Fork when you want to make changes to a project you do not have direct write access to, most commonly to contribute to open source. You make your changes in your fork, then open a pull request proposing that the original repository’s maintainers merge them in.

The typical open-source contribution flow

Fork the repository on GitHub. Clone your fork to your machine. Make changes on a branch. Push that branch to your fork. Open a pull request from your fork’s branch back to the original repository.

This is the standard path for contributing to a project you do not maintain, and it is worth knowing even if you never plan to touch open source, since it explains why so many GitHub tutorials mention both actions in the same breath.

Keeping a fork up to date

A fork does not automatically stay in sync with the original repository as it changes. Add the original as a second remote, conventionally named upstream, and pull from it periodically:

git remote add upstream https://github.com/original-owner/original-repo.git
git fetch upstream
git merge upstream/main

Without this, a fork left untouched for months can drift far enough behind that a pull request against it becomes difficult to merge cleanly.

Why this matters for your profile

Forks and their resulting pull requests are a normal, visible part of an active GitHub account, and open-source contributions in particular are one of the more convincing signals on a profile, since they show your code held up to another maintainer’s review standards, not just your own. For more on what does and does not show up on your public activity from this kind of work, see how the contribution graph actually works.

If that activity is starting to build into a real track record, resumefromgit.com turns a public GitHub username into a visual CV and a downloadable resume PDF, pulling directly from the repositories, forks, and contribution history already on the account.