Quick Tip: Sync a Fork with the Original via GitHub’s Web UI

By Bruno Skvorc

When you fork someone’s repository on GitHub, you’ll want to update your fork with any changes made to the original. There are various ways to do this. In this quick tip, Bruno describes how to update your fork via the GitHub website. Another option is to update your fork via the command line.

I often find myself having to update my fork of someone else’s repo to include the changes made to the original since the fork. In fact, we use this approach often in SitePoint’s Peer Review System as well.

Purely by accident, I’ve recently discovered a way to quickly and easily sync a fork with the original repo through the GitHub web UI, so no need to go commando (use the command line).

Note that the approach below does a merge commit, not a proper rebase. If you understand what this means, this is something that will matter to you. In a nutshell, the history looks different than when syncing via the command line as per Github docs. No real effect, but just a heads up!

Here’s a step by step guide, as applied to my out-of-date fork of Gatekeeper:

Step 1: New PR

Go to your own fork’s UI, and click the “New Pull Request” button:

New Pull Request Button

This will take you to a screen not too different from this one:

PR create screen

Step 2: Base Switch

If the option to try “switching the base” is there, click that.

Switching the base option

If the option isn’t there, switch the bases manually by using the provided dropdowns, and set them up so that your fork is on the left, and the original is on the right, like so:

Switched sources

Step 3: Send and Merge

Click the green “Create Pull Request” button. In the input fields that appear, give it a title like “Syncing from original”. Optionally, add a description.

Create a new pull request

Again, click the “Create Pull Request” button to actually send the PR. The result should be a typical PR screen:

PR screen with Merge button

Feel free to merge it with the “Merge Pull Request” button (and “Confirm Merge” afterwards), and you’re done!

Merged PR


That’s it – your fork is now in-sync with the changes made to the original, and you can start working on it without fear of conflicts.

Meet the author
Bruno is a coder from Croatia with Master’s Degrees in Computer Science and English Language and Literature. He’s the editor of SitePoint’s PHP channel and a developer evangelist for Diffbot.com. He avoids legacy code like the plague and when picking projects makes sure they’re as cutting edge as possible. He’s a treadmill desk enthusiast and active (board)gamer who sometimes blogs.
  • Christophe Coevoet

    This does not actually bring your fork uptodate. The fork will then contain more commits than the upstream repo (the merge commit), which means that the history quickly diverge.

    • http://www.bitfalls.com/ Bruno Skvorc

      Correct, hence the third paragraph note. But yes, this is best applied to repos that don’t care insanely much about the history’s cleanliness.

      • Christophe Coevoet

        What I mean is that your repo is out of sync with the upstream one. So if you start your new feature branch from your own master branch later instead of starting from the upstream master branch, the PR you will submit will contain a bunch of unrelated merge commits (once per usage of your tip in the repo), which will be rejected by most project maintainers.

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!