What the fork!

As a newcomer to Open Source projects or GitHub repositories, the term fork might seem very foreign to you. Last time you checked, you were trying to contribute to a project, not pick an eating utensil.

Copy Machine

When you fork a repository, GitHub presents the animation of a copy machine copying a book, and with good reason.

When you fork a repository on GitHub, for example github/training-kit, an exact replica of the repository is created on your individual user account. So, if you were to fork github/training-kit, you would then have a repository on your account called  username/training-kit.

Before we begin exploring our new repository, lets identify some terms that will make understanding forks a little bit easier. Our origin remote is going to be the new repository we just created on our account. So, for example https://github.com/octocat/training-kit.git would be an example of our origin. That same repository could create an upstream remote to https://github.com/github/training-kit.git. As you might have guessed, an upstream remote refers to the original repository from which you forked.

As we explore our repository, some really cool stuff happens. Aside from all of the content, the entire commit history of the project comes over when we fork the github/training-kit repository. Additionally the number of branches, releases, and contributors, are all duplicates of the upstream repository.

When you fork a repository with an open source license, you can begin making changes to the repository as if it was your own - because it is! Forking a repository opens the door to a whole new world of development. By forking an open source project, you can make changes to it without affecting the original repository, thereby safely creating a new version of the project on your own account. Additionally, you can help grow and evolve an existing project by proposing your changes be merged to the upstream repository via a pull request.

Up and Atom

The open source text editor Atom is assisted by a community that loves to contribute changes. The Atom repository has over 2,600 merged pull requests and some of them were provided from forks of the Atom repository. For example, pull request #15380 was created by a member of the open source community on their own fork of the repository. Something amazing about this pull request is that it isn’t direct changes to the code base of the Atom editor, but to the README.md file that informs every visitor to the repository about a multitude of things. Thanks to their detailed contributing guide, everyone from first time contributors to open source veterans know exactly how they should contribute bug fixes, new features, or fixes to misspelled words in the README file. 👍

Community Piloted Robots

The FIRST organization utilizes the idea of forking heavily. Every team that competes in a FIRST event utilizes base code that exists within one of FIRST’s repositories. Teams can modify the repository to give themselves an edge against the competition but can still receive updates to the core functionality from the FIRST organization.

This successful use of forking was accomplished with some foresight by the FIRST organizers. They created repositories that handled the different source code for the various robots that students were constructing, programming, and piloting in their competitions with a small caveat. Included in each repository is a folder that teams were instructed to make their changes in so that when new functionality was pushed out by FIRST, the customizations teams had made to their robots would not be overwritten when they updated their fork from the upstream remote.


Now that you have the foundations of forking down, give it a try! Find a repository that you’re interested in and create your own fork (there is a detailed guide in our Help Docs on how to do it here).

You can find more information on forks and how to collaborate with them in our Help Docs:

And, of course, if you have other questions or want to chat about this article further, feel free to leave a comment below.

Terminology Breakdown

  • Pull request : An opportunity to compare the changes you made on a branch to a deployed branch, typically the master branch.
  • Remote : A remote is the address or location of a repository outside of your local copy.
    • Origin remote : Typically, the remote assigned to the address where your copy of the repository is hosted, like on your GitHub account.
    • Upstream remote : Typically, the remote assigned to the repository that you originally forked from.

NOTE: Remote names actually don’t matter, but it helps to using naming conventions that the community recognizes. If you would like to identify the remote(s) in your project, type git remote -v in your command line application while in a git repository to list all of the remotes in your project



I forked a repository. I followed the instructions on https://help.github.com/articles/fork-a-repo/. I am stuck on the part where you have to “Change directories to the location of the fork you cloned in Step 2”. Any help? 

@harshitaarora so, if you cloned the repository locally, you are probably in the default folder of your Terminal application. Using the example provided in the instructions of the GitHub help documentation, If you type 

cd Spoon-Knife

You will “change directories to the location of the fork you cloned”. Basically, when you clone a repository, you don’t automatically open it. You need to open the repository by using cd followed by the repository name to open it after you clone it to your local machine.

Apologies on any delay in answering this question.

First thankyou for your great artical  ** it the best i came across** I beleave I already found the other you linked to, but I think there all missing one big thing that no one seems to address and was wonding if you could adress this or if this is to far out of your realm.

How do you keep every working together when every body make a copy.  To give you an example of what i talking about. 


I was lookig "Khan/live-editor"and not happy with there CLA.  I want to look for erverybody also who also forked it for this reason, but how can i do This?  There are over 160 forks. 


I think if you fork something or even create a branch of something it a good idea to put down the reason why …  so we don’t duplicate code un-needed-ly.

Is this the reson nobody covers this topic because it complicates things to much? 

One of the thing I read (following links everywhere and doing google search) was you should not create forks(wich i agree with) because it better to work with the creater on the original project. I think that should be meantion too.  Am i miss understanding the term of forking in your artical?