GitHub Fork vs. Clone: When and Why to Use Each

As a software engineer, you will collaborate with other software engineers on projects by sharing, reviewing and contributing code. You will need a version control tool to track the changes in these projects also. A version control tool is important because it helps traceability, provides backup for previous versions of the project and improves collaboration through the use of version branches.

Git is a version control software that tracks changes in projects. When you track changes with Git on your local computer, you can upload them to GitHub - an online platform that hosts code projects (as repositories. GitHub keeps a history of changes, allowing others to access the projects and contribute to their development.

What are Repository Permissions on GitHub?

When a repository is created on GitHub, only the creator has the permission to manage it, make changes to it and delete it. This begs the question - how do users contribute to repositories that they did not create?

Repository owners can give permissions to other users; they can also limit the scope of the permissions given. For example, a repository owner can give write-level permissions to another GitHub user which enables them to make changes to the repository, but excludes them from performing destructive actions like deleting branches, secrets or the repository itself.

Understanding repository permissions is essential to understanding when and why you should fork a project or clone it. 

What does it mean to Fork a Repository?

To fork a repository is to create a copy of the repository on your GitHub account. The repository that you forked from is called the upstream repository or original repository. The fork on your GitHub account is called a downstream repository. You have full access level permissions over your fork of a repository.

When forking a repository, GitHub allows you to optionally set a new name for your fork. It also gives you the option of copying only the upstream repository’s main (or master) branch to your fork.

‍

New changes to an upstream repository will not automatically update your forked copy. To keep the downstream up to date with the upstream, you have to sync it with the upstream repository.

When and why should you Fork a Repository?

You fork a repository when you don’t have write-level permissions to the upstream or original repository. Here are two reasons for when and why you should fork a repository:

• If you intend to make modifications to the project without interfering with the progress of the upstream repository. For example, if the upstream repository has features A, B, and C, and you want to add a feature D for your personal use, you can fork the repository and add feature D to your forked copy and use it.

Forking a repository to make modifications to it without interfering with the original project, is also done when the owner of the original project abandoned it without giving someone else the permission to manage it. You can fork the project and continue to work on it from your forked copy. An example is seald/nedb forked from louischatriot/nedb which is no longer maintained.

• If you intend to make modifications to the upstream repository but you do not have write-level permissions to it. In this case you would follow the steps below:

• Fork the repository
• Make modifications to your forked copy
• Create a pull request to the upstream repository to request that your modifications should be pulled to or included in the upstream repository

You may need to clone your copy to your local computer to make changes to it if the changes you need to make are many. After making your changes locally, you would commit them, push to your forked copy and create a pull request.

What does it mean to Clone a Repository?

To clone a repository is to pull a copy of all the repository’s data online to a local computer or to a remote computer in the cloud. It is similar to downloading files but with cloning, you get a history of the repository’s changes alongside the files.

You can clone any repository that you have read-level access to; that includes public repositories and repositories that you were invited to as a collaborator with at least read-level access. You can clone a repository from GitHub using

• The git clone command from a command line terminal
• The GitHub Desktop application

When and why should you Clone a Repository?

The main reason you clone a repository is to have a copy locally for use. When you have a copy of the repository on a computer, you can

• Make large scale changes to it easily. This is the case for when you fork a repository in order to make changes to it and propose the changes via a pull request. It is also the case for when you have write-level permissions to a repository and you want to make lots of changes to it and push it to GitHub.

• Run the project on your computer for use. For example, you can clone an android application’s repository, generate the executable file and use it on your android device.

Cloud-based hosting providers like Heroku and Railway clone repositories to remote virtual computers when triggered. These computers build the project after cloning and host the result of the build (usually a web application) on the internet for public use via a URL.

• Study the project to understand how it works. In this case, you may be interested in tinkering with the project to learn from it.

A Tabulated Summary of Comparisons between Forking and Cloning

Conclusion

You should fork when you want to contribute to a project without write-level access. Clone when you want to test, run, or modify the project’s content on a computer. Understanding when to use each puts you on the path to being a more collaborative and productive developer.

Now that you understand the difference, why not try both on your next open-source contribution?