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.
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.
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.
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: