Open source programming is all about being able to make your own changes to code others have written. To do that, you must branch off from the main repository, commonly called “forking” the repo, but it can be complicated if you don’t do it properly.
While this specifically applies to Github, as it is by far the biggest place for open source collaboration, the same principles will hold for Git repositories forked from any source. Github simply has extra tools that make some tasks easier, but if you prefer Git commands, we will show those as well.
Forking From Github
If you’re using Github, the easiest method to fork a repository is to click the “Fork” button, which will automatically make a new repository in your account and set up the remotes when you clone it. This will also make it show up in the “forks” tab of the source repo, and will show on your repo as “forked from X.”
If you don’t want that showing up, or aren’t using Github, you’ll need to clone manually.
If you are cloning it yourself, make sure to clone the repository properly rather than doing “Download ZIP.” If you don’t clone it through Git, it won’t copy over the version history and won’t be configured as a Git repository.
Configuring The Fork’s Upstream Remote
If you forked the repository from the Github website, the origin remote will point to your fork. However, it’s also useful to be able to pull from the original source repository, called the “upstream.” If they make changes, you’ll probably want to merge or rebase with the upstream remote.
Github has tools built in to do this automatically, so you don’t have to do this part, but if you want to use CLI tools, you’ll need to add back the original repo as a remote called “upstream“:
Forking From Git CLI
If you downloaded or cloned it from elsewhere, your repository will still be linked to the remote you cloned it from. This is likely what has happened if you downloaded a repo before intending to fork it. Luckily, this is perfectly fine, and you will simply need to configure it yourself.
If you want to integrate new changes from the source, you’ll still want the source remote, but it shouldn’t be the default “origin” remote. So, you’ll want to rename the default remote from “origin” to “upstream.”
And then add your own remote as the new “origin,” which you will probably need to make manually if you plan on pushing it back to Github:
Once that’s done, you’ll probably need to set the default remote for each branch to your fork:
And push to origin, which will upload the files to your new repository.
Updating With New Changes
If you forked from Github, one of the nice features is that it keeps track of the upstream source and allows you to perform merges through the Github website. It’ll show you when it’s up to date, and when it isn’t, you’ll have the option to merge.
If you want to do it through the Git CLI though, there is a better way. Rebasing is similar to merging, but keeps a flat commit heirarchy and doesn’t lead to unnecessary merge commits. Most of the time, you’ll want to rebase when integrating upstream changes, but this is up to you. Merging is also a valid strategy, especially if you’re not merging very often.
To integrate changes, you will need to fetch the upstream remote, checkout the master branch, and rebase to upstream/master.
After this, you may need to force push if this is the first time rebasing:
Making Pull Requests
If you forked from Github, this is also easy. You can simply press “Contribute” and it will automatically open a pull request.
If not, the process is still simple. Head to the upstream repository, and under the “Pull Requests” tab, select “New Pull Request.”
Then, you will need to select “compare across forks” and find your fork repository. Select the branches you want to merge, and click “Create pull request.”
You can continue working on your fork, and merging in pull requests as needed. If you’re doing this a lot, you may want to consider setting up your own branches locally for your features, and then merging into the target upstream branch when you want to make a PR. This can help with keeping PRs on topic and focused on one feature branch at a time.
