The difference between forking and cloning a repository

The difference between cloning and forking a repository on GitHub

Just a couple weeks ago, we shared some information with you about forking a repository and the cool things you can do with this functionality. Now you might wonder - what is the difference between forking a repository and just cloning it?

Well, ruminate on the mysteries of these features no more! In this article we’ll go over the differences between the two methods so that you can determine the best option to use when working on a project.

Forking

A fork is a copy of a repository that allows you to freely experiment with changes without affecting the original project. A forked repository differs from a clone in that a connection exists between your fork and the original repository itself. In this way, your fork acts as a bridge between the original repository and your personal copy where you can contribute back to the original project using Pull Requests.

Forking a project is as easy as clicking the  Fork  button in the header of a repository. Once the process is complete, you’ll be taken right to your the forked copy of the project so you can start collaborating!

Check out our help article for more information about forking, including steps on how to keep your fork synced up with the original project.

Cloning

When you create a new repository on GitHub, it exists as a remote location where your project is stored. You can clone your repository to create a local copy on your computer so that you can sync between both the local and remote locations of the project.

Unlike forking, you won’t be able to pull down changes from the original repository you cloned from, and if the project is owned by someone else you won’t be able to contribute back to it unless you are specifically invited as a collaborator. Cloning is ideal for instances when you need a way to quickly get your own copy of a repository where you may not be contributing to the original project.

To clone a repository, head over to the main page of a project and click the Clone or download button to get the the repository’s HTTPS or SSH URL. Then, you can perform the clone using the git clone command in your command line interface of choice. For a step by step guide, check out the cloning a repository article.

Frequently Asked Questions

Will my fork contain the same data as the original project?

Forking a repository will copy the main data such as files and code. Issues, branches, pull requests and other features, however, will not copy over to your fork. Instead your fork will start the same way as a newly created repository, but with all of the content present at the time of forking, so you can work on it as a fresh project.

When should I fork a repository?

If you want a link to exist between your copy of a project and the original repository, you should create a fork. This will allow you to make changes to your fork, then open a pull request to the original to propose your changes. Forking is ideal for open-source collaboration, as it allows for anyone to propose changes to a project that the original repository maintainer can choose to integrate.

If I want to back up my repository, should I clone it?

Cloning a repository is a great way to create a backup. However, while your clone will copy over Git data like files and commit history, it won’t bring over issues, pull requests, and other GitHub elements.

When should I clone a repository?

Do you require a copy of a project, and do not need to sync your copy with the original project? If so, a clone is more suitable because it does not share a connection with the original repository.

Further Reading

Now that you know which format to use when making a new copy of a project, here are some other resources for getting comfortable working with forks and clones:

46 Likes

I didn’t understand the part “Unlike forking, you won’t be able to pull down changes from the original repository you cloned from, and if the project is owned by someone else”

after cloning a repository to local if we do ‘git pull origin <branchName>’

Aren’t we syncing the changes with remote main repository?

And similarly when we do push we could push the changes to repository. 

Is it different for within organization git repositories than the repositories for open source projects?

Thank You.

24 Likes

Thanks for the explanation, it really helps top better understand the tool & environment. 

3 Likes

I’m really confused by this article. Isn’t the difference between cloning and forking the opposite of this explanation? When I clone a repo, I can push and pull changes made to the original. But with a fork, it is my own repo with no connection to the original repo? Thanks.

13 Likes

@fernandez wrote:

The difference between cloning and forking a repository on GitHub

 

Just a couple weeks ago, we shared some information with you about forking a repository and the cool things you can do with this functionality. Now you might wonder - what is the difference between forking a repository and just cloning it?

 

Well, ruminate on the mysteries of these features no more! In this article we’ll go over the differences between the two methods so that you can determine the best option to use when working on a project.

 

Forking

 

A fork is a copy of a repository that allows you to freely experiment with changes without affecting the original project. A forked repository differs from a clone in that a connection exists between your fork and the original repository itself. In this way, your fork acts as a bridge between the original repository and your personal copy where you can contribute back to the original project using Pull Requests.

 

Forking a project is as easy as clicking the  Fork  button in the header of a repository. Once the process is complete, you’ll be taken right to your the forked copy of the project so you can start collaborating!

 

Check out our help article for more information about forking, including steps on how to keep your fork synced up with the original project.

 

Cloning

 

When you create a new repository on GitHub, it exists as a remote location where your project is stored. You can clone your repository to create a local copy on your computer so that you can sync between both the local and remote locations of the project.

 

Unlike forking, you won’t be able to pull down changes from the original repository you cloned from, and if the project is owned by someone else you won’t be able to contribute back to it unless you are specifically invited as a collaborator. Cloning is ideal for instances when you need a way to quickly get your own copy of a repository where you may not be contributing to the original project.

 

To clone a repository, head over to the main page of a project and click the Clone or download button to get the the repository’s HTTPS or SSH URL. Then, you can perform the clone using the git clone command in your command line interface of choice. For a step by step guide, check out the cloning a repository article.

 

Frequently Asked Questions

 

Will my fork contain the same data as the original project?

 

Forking a repository will copy the main data such as files and code. Issues, branches, pull requests and other features, however, will not copy over to your fork. Instead your fork will start the same way as a newly created repository, but with all of the content present at the time of forking, so you can work on it as a fresh project.

 

When should I fork a repository?

 

If you want a link to exist between your copy of a project and the original repository, you should create a fork. This will allow you to make changes to your fork, then open a pull request to the original to propose your changes. Forking is ideal for open-source collaboration, as it allows for anyone to propose changes to a project that the original repository maintainer can choose to integrate.

 

If I want to back up my repository, should I clone it?

 

Cloning a repository is a great way to create a backup. However, while your clone will copy over Git data like files and commit history, it won’t bring over issues, pull requests, and other GitHub elements.

 

When should I clone a repository?

 

Do you require a copy of a project, and do not need to sync your copy with the original project? If so, a clone is more suitable because it does not share a connection with the original repository.

 

Further Reading

 

Now that you know which format to use when making a new copy of a project, here are some other resources for getting comfortable working with forks and clones:

 

@fernandez wrote:

 

Unlike forking, you won’t be able to pull down changes from the original repository you cloned from

This is false, or not explained properly. 

When I clone a project that belongs to me, from Github to my local machine, it absolutely stays in sync both ways, and allows me to push changes back up to the original. No forking involved.

Obviosuly if I clone a project that doesn’t belong to me, I can’t contribute changes back to original.

I agree with other comments here, this article makes understanding the concept confusing.

11 Likes

@jaywalker291 & nobody is going to, ever, update it! xD

2 Likes

Thank you all very much for adding your feedback here, we are looking into it and will make the edits necessary to make the article clearer. My apologies for taking so long to address your concerns.

1 Like

Isn’t that what pull requests are for?

If it’s done wrong and you can do it better, why not create a pull request and submit an update?

GitHub staff; review and fix this article. Cloning & Forking is the different contribution style and explained in this article. Please check docs.github.com & experience before writing.

2 Likes

Given some of the feedback in the thread I will take a stab at adding a bit more flavor in a few areas.

Fork is actually not really a git concept itself if I am not mistaken, it’s a common way of referencing a pattern that is used. Each VCS provider can create their own definition of what is a fork and what specifically they do for you when you click the magic button or use the API. The reality is that you are doing a git clone however you are updating the configuration so that you have a distinct location that is a copy of the repository. You can then choose when working with your local repository through the use of remotes to decide if you are interacting with your copy or the upstream. When you locally clone a repository you will automatically have the server setup your initial remote for you

Pull requests are a native git feature these days though they are realistically little more than a message with a patch file that is submitted to the remote specified. The reason we can create a pull request from a “forked” repository into the “source” is because they share a common history and the patch file will tell us how to proceed. Git is a series of pointers of data rather than just storing the data. If you are interested I have a more lengthy post here Why is it that Pull Requests and Issues share the same numbering sequence on GitHub? that talks more about some of the internals of a pull request.

As an open source maintainer I often help folks with stale pull requests where they need to integrate changes in the project that does not exist in their fork. Locally adding a remotes and rebase/merge are the key components to handling this integration challenge; which is required when the relevant code has been modified in some way.

For my community I have the following contributing template that walks through a typical fork as well as how to setup a one way (pull/fetch) remote. If you have the permissions to write/push to the remote and it’s been configured to you can absolutely move changes from one remote to another.

$ git clone https://github.com/$user/<%= repo_name %>/
# or: git clone git@github.com:$user/<%= repo_name %>.git

$ cd <%= repo_name %>

$ git remote add upstream https://github.com/sensu-plugins/<%= repo_name %>.git
# or: git remote add upstream git@github.com:sensu-plugins/<%= repo_name %>.git

# Never allow a push to upstream master
$ git remote set-url --push upstream no_push

# Confirm that your remotes make sense:
$ git remote -v
3 Likes

Just want to add that a fork is not really a copy of a repository (so far as I can tell), it is in fact just a set of branches into the same repository.

If two users fork a repo, then the fork operation creates a set of branches for each user and points these at the same commits as the actual branches.

Now a branch name must be unique within a repo, so I suspect that the fork branches are actually named something like username.branchname but the GitHub GUI and API mask the username part.

Every time you push commits to your fork you are actually pushing them to the main repo!

But the main repo never exposes the per-user branches, they simply get filtered out so any commits in these branches are invisible unless you are looking at it via the fork.

So think of a fork as a virtual repository, just a set of branches in the main repository.

You can prove this by getting the commit ID of a commit on some branch in your fork that is not yet merged to the main repo.

Then navigate to a commit that is on the main repo, overwrite the commit ID with the one from the fork branch and press Enter.

You’ll see the commit displayed and the URL looks just like the commit is in the main repo but you also see this message:

Everything suggest that the commit is in fact in the main repo but on a branch that is part of someone’s fork.

This explains why forking even a huge repo takes just a few seconds.

2 Likes

Спасибо! Наконец -то нашла то что мне очень сейчас требуется!

1 Like

Thanks for that link. It was helpful.

Your welcome; Those are basic principles; I advice to rookies around me → first learn git command and parameters (https://git-scm.com)

A year and two months have passed, and there have still been no edits. It is still confusing. My experience with git has been the exact opposite. Without some kind of edit or explanation, this article should really be taken down before some young programmer takes it as gospel.

Thanks c’est génial
:+1: je suis entièrement satisfait de ce moteur de recherche merci

interesting! i like that feature tho :thinking: