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.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.