Trusted answers to developer questions
Trusted Answers to Developer Questions

Related Tags

git
community creator

What is the difference between forking and cloning in Git?

Arash

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

When interacting with Git and Git hosting platforms (like GitHub, BitBucket, GitLab, etc.), some terminology may be confusing. Among these terminologies is forking and cloning a repository. Both of these terms appear to do the same thing — create a copy of an existing repository — but what is the difference between them?

The quick answer

Forking creates your own copy of a repository in a remote location (for example, GitHub). Your own copy means that you will be able to contribute changes to your copy of the repository without affecting the original repository.

Cloning makes a local copy of a repository, not your own copy. Think of it as downloading a repository onto your local hard drive. Unlike forks, clones have references to their original repositories.

The picture below shows a visual explanation and compares the two:

A summary of the difference between forking and cloning.

More detailed explanations

Forking

Forking creates your own copy of another existing repository in the remote location; when you fork, nothing changes in your local storage. Instead, a new repository will be initiated with the contents of the existing repository copied over on your remote account.

In a way, forking can be analogous to handling files in Google Drive as it refers to making a copy of a document (say, a Google Docs document) that is yours to edit as much as you’d like. The main difference here is that forks retain a link to their original repositories (allows for specific use cases like pull requests to happen easily), but you can still clone and make changes to this fork.

When should I fork a repository?

You will want to fork a repository if you would like to integrate changesi.e., your contributions to an existing open-source repository.

In this case, you would create a fork, work on the changes you want to implement, then create a pull request to merge the changes you’ve made from your fork into the original repository.

Forks create a safe environment for the original repository – no matter how much experimentation you do in your own fork, the original repository is not affected at all!

I’m still a little confused…

Here are some great sources to help you further:

Cloning

In order to do work on your source code, you’ll need to have a place on your local storage where your source code lives – but, how can you get the contents in your remote repository into your local storage to work on it?

That’s where Cloning comes in.

Cloning creates a copy of a repository and retains a link to its original repository. You can only pull, fetch, and push back to that same repository. If you are trying to implement your own changes, cloning and pushing may not work as there are protection measures in place to ensure that the contents of repositories aren’t modified by anyone but the repository owners and collaborators.

If we take another look at the the Google Drive analogy, we can see that cloning is like downloading the file to your computer from a read-only folder. While you can make changes to your local, cloned repository, you’re most likely not able to implement those changes to the original copy due to #key# the protections the file has against you: you’re not permitted to change the content!#key#. In this case, a fork would be the better option.

When should I clone a repository?

If you would like to make changes directly to a repository you have the permission to contribute to, then cloning will be the first step before we implement the actual changes and push.

If you don’t have permissions to contribute to the repository, but would like to implement changes anyway, a fork is the way to go.

I’m still a little confused…

Here are some great resources to help you further:

Wrap-up

This may be confusing since forking and cloning appear to be similar.

However, remember, forking creates your own copy of a repository, meaning that you can make changes as much as you’d like. If you want, afterwards, you can create a pull request to integrate your changes to the original repository.

Cloning is more of a download of a remote repository onto your computer. If you don’t have the permissions to make changes to it, your push attempt will be rejected by the remote. Otherwise, your changes will be directly integrated into the repository when you push.

Here’s a little quiz for you to check your understanding. Have fun!

Cloning and Forking: What’s the Difference?

1

If you would like to retrieve the source code but not contribute, which is more suitable: cloning or forking?

A)

Cloning

B)

Forking

Question 1 of 40 attempted

RELATED TAGS

git
community creator

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

Keep Exploring