Back

Working With Forked Repos

Fetching upstream and things

🍿 1 min. read

Though I've been building web apps for many years, my direct experience with contributing to open source projects is surprisingly limited. Thus when I found myself forking and maintaining a fork as I submitted several PR's for a single project over time I was a little lost with what to do.

So here are some things I've learned thus far.

Why Fork, and How do I Fork?

Github, Gitlab and other source-code repositories allow for you to "fork" code. I previously thought this was to split work into a different direction, but in fact its also to give a developer control over proposed changes they'd like to push back to source. Thus, submitting a PR to an open source repository looks like this:

  1. Click Fork on the source-code repository
  2. Clone your newly forked repository
  3. Make your changes on a new branch
  4. Push your branch to your forked repository (A misconception I had was you may not push a branch to many open source repositories directly, this is intentional)
  5. Create a PR that merges your branch from your fork to the original non-forked repository

Updating the Forked Master Branch

Over time your forked repository will get out of date. A common scenario is desiring to get the latest master from the source repository.

git remote add upstream ORIGINAL_PROJECT_CLONE_URL
git fetch upstream
git checkout master
git rebase upstream/master

Now you may do all the standard things you wish, such as merging master into your current branch git merge master to stay up to date with your proposed changes.

Back