The difference between forking and cloning a repository on GitHub

[fernandez]

Cloning and forking repositories on GitHub

One of the main benefits of using a version control system is the ability to acquire your own copy of a project quickly and easily. The two most commonly used methods for copying a repository on GitHub are cloning and forking.

Tip: If you just need an archive of repository contents, click the Code button on its home page and look for Download ZIP.

What is cloning?

Repositories created on GitHub exist as remotes. When you clone a repository you are creating a local copy on your computer that you can sync with the remote on GitHub. Cloning is ideal for contributing directly to a repository alongside other users while utilizing branching and other collaboration tools to manage changes.

Tip: Cloning a repository can be used to create a backup that is regularly kept up to date, but it's important to note that although your clone will copy over Git data like files and commit history, it won't bring over issues, pull requests, and other GitHub elements.

To clone, head to the main page of a repository and click the green Code button. In the dropdown that appears you will have the option to clone over HTTPS, SSH, or by using the GitHub CLI.

What about forking?

A fork is a copy of a repository that allows you to make your own changes without impacting the original project. A fork differs from a cloned copy in that it doesn't allow for direct collaboration with the root using local commands like git push and git pull. Instead, your fork exists on GitHub and you can contribute back to the original project using Pull Requests. You can also synch your fork easily to keep it up-to-date with changes from the root repository.

Forks are ideal for situations where the root repository is serving as a basis for further iteration, or to play around with ideas -- instead of starting a project from scratch you can use an existing repository as a foundation then take it to the next level!

Tip: Keep in mind when working with a fork of a private repository that GitHub will consider the owner of the root repository to have ownership of its forks as well. This means that when a private repository is deleted any of its forks will also be removed. This isn't something to worry about for public repositories as in that case the fork is owned by the fork owner and will be detached or re-routed in the case a root is deleted.

Forking a project is as easy as clicking the Fork button in the header of the repository home page. Once the process is complete you'll be taken to your forked copy where you can start collaborating! Forking a repository will copy data such as files and code but Issues, branches, pull requests and other features won't join the party. Instead, your fork will start the same way as a newly created repository so you can begin work on it as a fresh project.

Further Reading

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

• Understanding the GitHub Flow
• Configuring a remote for a fork
• Which remote URL should I use?

[mdriyadkhaan]

Good

[7und3dpy]

gud luck

[kolumnin]

Thank you.

[CrytoCodeWizard]

so interesting and learned alot.

[savaonepunch]

So if I want to contribute to a random repo, do I have to fork it and create a pull request? Or can I just clone it and create a new fork on the original repo?

[Gainpay]

Pls I just join , I need someone to guide me

[cx0y]

if you wanna test some projects, just clone its repository and if you wanna contribute to some repository, best practice is, create a fork, then commit your contribution and create a pull request to its upstream!

[om4rAb]

Let's say I am working on a restaurant project with some guys, So I need to fork it then clone it and do the work then push to the repo I forked then make a pull request to the originale repo right ?

[SaadHusayn]

yes you are right, but if you just want to test the project, you clone the original repo and work with that.

[frzyb]

no

[dserodio]

Not "genuine owner", but original author. The original author should be credited, you shouldn't "hide" the origin of the code. Even if the license allows, it's bad manners.

[arijhajji-1]

thank you

[Tinoet]

Good read. Thanks.

[3kh0]

Thank you for this post, I wanted to ask if #38021 is on the roadmap and could you please add it if possible?

[SPerju]

Interesting

[Shaker-Al-Muzaini]

Thank you for this post

[MoussaAmbassador]

Thanks for sharing

[airyadriana]

The article says: Tip: Keep in mind when working with a fork of a private repository that GitHub will consider the owner of the root repository to have ownership of its forks as well. This means that when a private repository is deleted any of its forks will also be removed. This isn't something to worry about for public repositories as in that case the fork is owned by the fork owner and will be detached or re-routed in the case a root is deleted.

Question: We just created an organization in which a particular team wants to work with another organization's existing private repository (repo A) to improve their code so we don't start from scratch. However, we don't want to contribute back to repo A. My concern is that this article mentions that if repo A gets deleted, then our fork (if we fork) will be removed. Should we clone it to our Organization's team's repository instead?
Thanks!