1. Introducing Forking
A fork of a repository is essentially just a copy of the repository. In the spirit of open source, forking is a way to share with and learn from other developers.
Developers can have many motivations for forking a repository, but three of the most common reasons are to
» Contribute to someone else’s project
» Use someone else’s project as a starting point
» Experiment with someone else’s code without making changes to their project
If you aren’t the owner or a collaborator on a project, you’ll have to fork the repo if you want to do anything other browse the files. If you plan on making any changes to a repo where you aren’t an author or collaborator, fork the repo first so that you’re in the correct state as you start to explore and modify the code. Don’t worry, though, if you forgot to fork — see the section “Getting unstuck when cloning,” later in this chapter, for help you.
Prior to GitHub, a fork of an open source project tended to have a negative connotation. It wasn’t just a copy of the source code, but a split in the community. A fork implies a fork in the road, where one group takes the project in a new direction. For example, Joomla is a fork of the Mambo project by a group of people that felt like a company had too much control. In practice, forks tend to be good for the overall ecosystem because they introduce new ideas. In some cases, the best ideas in the fork make their way back into the original project, such as when EGCS, which forked from GCC, had its changes merged back into the GCC project. On GitHub, forks tend to be more like short-lived branches that are either merged back into the main code or deleted.
2. Cloning, Forking, and Duplicating
When you clone a GitHub repo, you’re creating a local copy of the project on your computer. Forking a GitHub repo creates a copy of the repo on your GitHub.com account, and from there, you can clone the repo. A link between the original repo and the one you forked will remain, allowing you to pull changes made on the original repo into your copy and push changes that you make on your copy to the original copy.
Duplicating a repo is when you make a copy that no longer has a link to the original copy. Duplication isn’t a usual part of an open source workflow because it makes it more difficult to push changes back into the original repository. Even so, duplicating a repo can be useful sometimes, such as when the original project is no longer active and you plan to keep the project alive with your fork.
3. Cloning a Repository
Any public repo can be cloned, and you can run the code on your computer and make changes to the code. But you won’t be able to push those changes back to the remote repo if you don’t have push permissions to the repo. Chapter 4 describes how to clone a repository in GitHub Desktop when you’re the owner. The process is the same whether you’re an owner, collaborator, or visitor.
Before you clone a repository, you should verify that you’re able to push changes to it. The easiest way to verify this ability is to go to the repository home page. If you see a Settings tab on the right side of the home page, then you likely have push rights. If you don’t, you likely have to fork the repo first. Alternatively, you can try to edit a file on GitHub.com, and if you get the message shown in Figure 6-1, then you don’t have permission to directly contribute to the project.
If you do end up cloning a repository where you don’t have permission to contribute to it, you can end up making changes and not being able to push them. The section “Getting unstuck when cloning,” later in this chapter, gives steps for how to get out of this state.
After you have a repository cloned on your local computer, you can view and modify metadata about it in your terminal. Open the terminal and go to a directory where you have a GitHub repository. If you need an example, clone https:// github.com/thewecanzone/GitHubForDummiesReaders by typing
$ git clone https://github.com/thewecanzone/
GitHubForDummiesReaders
Cloning into ‘GitHubForDummiesReaders’…
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 15 (delta 4), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (15/15), done.
$ cd GitHubForDummiesReaders
You can verify where the remote/target repo is with the following command:
$ git remote -v
origin https://github.com/thewecanzone/
GitHubForDummiesReaders.git (fetch)
origin https://github.com/thewecanzone/
GitHubForDummiesReaders.git (push)
If you cloned the same repo as we did, you see the exact same origin URLs for fetch and push. You should see that the remote repo is one owned by thewecanzone and not sarah-wecan. Alternatively, if you run the same command on a repo that you own, you should see your username. For example, if we run the command in the directory where I cloned my website repo that we create in Chapter 4, I would see
$ git remote -v
origin https://github.com/sarah-wecan/sarah-wecan.github.
io.git (fetch)
origin https://github.com/sarah-wecan/sarah-wecan.github.
io.git (push)
If you try using the command on a Git repo that doesn’t have a remote origin (meaning it isn’t hosted on GitHub.com or any other remote place), you simply won’t get any information back. For example, in Chapter 1, we create a simple Git repo called git-practice. Running the command in that directory gives you nothing back:
$ git remote -v
Source: Guthals Sarah, Haack Phil (2019), GitHub for Dummies, Wiley.